TCP 연결이라는 착각에 대해

TCP는 연결지향 프로토콜이라고 배웁니다. 그렇다면 '연결'은 도대체 뭘까요? 무엇이 연결됐다는 결론을 얻게 하나요? 이 주제까지 생각한다면 TCP Session hijacking 같은 보안 문제에 대해서도 쉽게 이해할 수 있습니다!

[@jwp3479]

안녕하세요 교수님, 4년전 군대에서 컴퓨터에 관심이 생겨 교수님 C강의로 프로그래밍에 처음 입문했는데, 시간이 흘러 벌써 해외 전문대에서 편입 준비를 마치고 컴퓨터과학과로 원서지원을 마무리 했습니다 ㅎㅎ 교수님이 알려주신 포인터와 메모리 개념은 아직까지도 모든 과제든 공부에 도움이 되는 것을 보면서 처음 공부 시작이 정말 좋았다는 생각을 매번 안할수가 없었던거 같네요 양질의 강의 올려주셔서 정말 감사하고 또 앞으로도 명강의 수강할 수 있었으면 좋겠네요 :D 항상 건강하시고 응원합니다!

[@nullnull_not_eq_null]

전공자가 될 사람이라면 메모리 디버깅은 할 줄 알아야 합니다. 감사하게도 제 생각이 맞다는 것을 다시 한 번 확인해주셨네요. ^^ 열공하시고 좋은 성과 거두시기 바랍니다. 건투를 빕니다!

[@dtd6797]

와 진짜 도움 너무 많이 되네요! 감사합니다!

[@nullnull_not_eq_null]

도움이 되셨다니 다행입니다.

[@jerryk0269]

아... 오늘 강의를 들었더니 드디어 "연결"이라는 개념 자체가 좀 와닿네요. 역대급 강의가 정말 많은 것 같습니다 선생님 TCP 연결은 3-way handshake로 이루어진다. (segment 단위) 3-way handshake란 클라이언트와 서버 간 서로의 sequence 번호를 교환하는 행위이다. 이 과정에서 겸사겸사 MSS(Maximum Segment Size)와 혼잡 제어 방법(최근 대부분 SACK)도 교환한다. client -> server SYN (client-sequence) 전송 server -> client SYN(server-sequence) + ACK(client-sequence) 전송 (한 패킷 안에 Sequence number, ACK Number 헤더 영역이 따로 존재한다) client -> sever ACK(server-sequence) 전송 연결 없이 UDP처럼 그냥 패킷 전송하면 되는것 아닌가? => NO. TCP 방식은 서로 어떤 시퀀스 번호로 보내는지 알고, window size를 알아야지 패킷 유실을 방지하고 흐름을 제어할 수 있다. 프로토콜의 특성이기 때문에 3-way handshake라는 "초기화"작업이 선행되어야 패킷을 교환할 수 있는 것. 데이터를 주고 받으려면 우선 프로토콜이라는 "약속"을 지켜야 한다. 송수신 측은 각각 커널 단에 상대방의 sequence 번호와 ack 번호를 버퍼에 저장한다. 원하는 곳으로 데이터를 전송할 때 해당 버퍼를 들여다 보고 버퍼에 들어있는 값들을 헤더에 써서 전송한다.

[@nullnull_not_eq_null]

열공 모드로 달리시는 군요! 좋은 결과로 이어지기를 응원 합니다. 감사합니다. ^^

[@user-in5gx2lm4e]

대표님! 강의를 다시 시청하는 중에 질문이 생겨 댓글을 남깁니다. 3-way handshake과정에서 TCP연결을 위해 사용되는 패킷은 payload가 없으며 TCP헤더의 설정값들의 변화(Sequence Number등)만을 인지하고자 주고받는 패킷인가요?

[@nullnull_not_eq_null]

네, 데이터를 주고 받는 것은 아니므로 Payload가 없습니다. 참고하시기 바랍니다. ^^

[@chopchop838]

안녕하세요 대표님!! 항상 잘 듣고 있습니다~~ 학습 중 궁금한 부분이 있어서 질문드립니다! 많은 글들에서 SYN를 만들 때 랜덤 값을 지정하는 이유를 다음과 같이 설명합니다. “난수가 아닌 순차적인 number가 전송된다면 서버가 이전의 커넥션에서 오는 패킷으로 인식할 수 있다. 이러한 가능성을 줄이기 위해 난수로 만든다.” 이 말이 이해가 잘 가지 않는데 맞는 설명일까요? 클라이언트와는 다르게 서버는 포트 하나만으로 요청을 받기 때문에 소켓을 구성할 때 (클라이언트 ip, 클라이언트 port, 서버 ip, 서버 port)와 같은 정보를 통해 수많은 클라이언트들을 구분하고 통신을 하겠구나라고 이해했습니다. 즉 이러한 수많은 소켓들을 하나씩 listening 하면서 서버가 어떤 클라이언트로부터 온 요청인지 특정지을 수 있다고 생각했습니다. 하지만 위의 설명대로라면 “서버로 들어오는 모든 패킷에 대해 SYN를 통해서만 클라이언트를 구분한다”라고 결론이 나서 의문이 들었습니다. 위의 난수에 대한 설명은 소켓 생성 전, 3-way handshaking 과정에서만 해당하는 내용일까요? 아니면 제가 완벽히 잘못 이해하고 있는걸까요.. 😭

[@nullnull_not_eq_null]

Seq. number를 난수로 만들어서 예측을 피해야 하는 이유는 TCP Session hijacking attack 때문입니다. 제가 '연결은 착각'이라는 주장을 반복하는 이유는 연결의 판단 근거에 Seq number가 사용되기 때문이기도 합니다. 누군가 두 End-point간의 TCP seq number를 정확히 예측해서 맞춰내고 그에 따른 응답을 할 수 있다면 TCP session을 가로챌 수 있습니다. 그리고 서버는 특정 포트 번호하나로 연결을 받지만 세션 하나를 식별할 때는 원격지 IP + Port 번호를 조합해 식별하므로 문제가 없습니다. 여기서 TCP seq number는 결합해서 생각할 필요가 없습니다. 단순 식별의 문제와 TCP session의 문제는 분리해 생각하는 것이 맞겠습니다. 참고하시기 바랍니다.

[@chopchop838]

​@@nullnull_not_eq_null 답변 감사합니다! 그렇다면 3-way handShaking 후 클라이언트 A와 서버 B가 세션이 형성(양쪽에 소켓이 형성)된 상태라고 가정한다면, 해커 C가 A-B 사이에서 사용되는 TCP seq number를 예측하고, 클라이언트 A와 동일한 IP, Port로 자신의 패킷을 조작한 후 서버에 요청을 보낸다면(이 때 해커가 클라이언트 A에게는 서버 B가 세션을 종료시킨 것처럼 FIN을 보내고) 서버 B는 정상적인 클라이언트 A와 아직 통신하는 중이라 믿고 해커 C와 통신하게 되는 경우라고 생각하면 맞게 이해한 걸까요? 맞게 이해한거라면, TCP 세션 형성 후에는 적어도 두 end-point간 누군가 도청을 할 수는 있더라도 세션에 껴들을거라고는 생각하지 못해서 조금 충격적입니다.. 결국 sequence number 하나로 연결이 구분된다면 설령 이를 난수로 지정하더라도 그리 안전해보이진 않다는 생각이 들었습니다. 떠오르는 해결 방법으로는 아예 IP, Port 자체를 탐지 못하게 암호화해야한다는 생각밖에 들지 않는데, 사실 제가 아는 SSL 같은 암호화는 HTTP 계층 암호화라 소용없을 것 같습니다. 간단한 솔루션에 대한 키워드를 알려주실 수 있으실까요!

[@AURA.1]

해킹당했는지 도대체 뭐가 문제인지 찾다가 영상보고 답을 찾았네요~감사합니다

[@nullnull_not_eq_null]

부디 큰 피해는 없으시기 바랍니다. 건투를 빕니다!

[@shera1004]

잘들었습니다.ㅎ

[@nullnull_not_eq_null]

잊지마세요. 연결은 객관성 없는 자기 판단에 불과합니다. 열공하세요~~~! ^^

[@devdevjb]

연결은? 착각이다 , TCP연결은 3way handshake로 이루어 지는데 , 이것은 seq번호 교환 + mss교환 + 정책(혼잡제어 관련) 교환 (요즘은 SACK사용) 이다 , 이것에는 보안성이 없다는것에 명심하자!! 항상 좋은 강의 감사드립니다!

[@nullnull_not_eq_null]

네, 착각입니다. 즉, 실제와 다를 수 있다는 것이죠. 열공하세요~~~! ^^

[@user-nb8du7ie1k]

안녕하세요 교수님 본 강의에서 시퀀스넘버를 이야기 해주시면서 2^32는 4GB다라고 말씀 해주셨는데 시퀀스넘버는 단순 조립순서(퍼즐)인거지 이게 4GB랑 크게 연관점이 있는건가요 ? 아니면 단순하게 팁으로서 설명 해주신건가요 ? 추가로 1.시퀀스넘버가 실제 4GB가 넘을 수 있는건가요? 2.시퀀스넘버는 TCP소켓이 계속 유지되고있으면 증가하는건가요? (HTTP 커넥션은 유지 되어 있는 상태) 3.64bit os를 지원한다면 세그먼트의 사이즈도 64bit로 증가하는건가요?

[@nullnull_not_eq_null]

조립 순서입니다. 하지만 송신한 바이트 수만큼 증가하므로 이 번호의 증가량을 계산해 송신한 데이터 량을 측정할 수 있습니다. 시퀀스 번호는 감소할 수 없습니다. 다만 4GB(32비트 한계)를 넘어가면 범위를 넘어가 0위치로 되돌아 갑니다. 그러나 증가 값 계산은 지속할 수 있으므로 넘어도 문제는 없습니다. 끝으로 운영체제와는 무관합니다.

[@marunarae550]

3way hand shake 번역하실때 빵 터졌네요 ㅋㅋㅋㅋ 세방향 악수하기?

[@nullnull_not_eq_null]

전문용어라는 것 번역해보면 꽤 웃길 때가 있습니다. Tunnel도...^^;;;

[@wjyang71]

3번 패킷을 주고받는거니 3번 악수하기정도 아닐까요?

[@HellScavenger]

현대 네트워크 환경에서 TCP 헤더의 Sequence Number 필드는 MAX 값까지 얼마안가 금방 차게됩니다. 이 경우 보통 0으로 다시 복귀하게 되지만, 여러가지 사유로 그렇게 되지 않을 수도 있습니다. 이 경우 네트워크 장애가 발생할 수 있을까요 ^^? 발생한다면 어떤 현상으로 관측될까요? 해당 장애가 발생한다면 이를 어떻게 진단하고 해결할까요 ^^?

[@nullnull_not_eq_null]

Seq 번호는 32비트 부호가 없는 정수형입니다. 따라서 4GB까지가 한계입니다. 한 TCP 세션에서 4GB이상 통신하면 Seq 번호는 다시 0으로 돌아옵니다. 그리고 이것은 장애가 아닙니다. '그렇게 되지 않는 경우'는 어떤 경우일까요??? 아마도 VPN 같은 곳에서 정책적으로 데이터 송/수신량에 대한 제한을 두는 경우가 있는데 그 경우를 생각하신 것 같습니다. 대표적인 TCP 장애에 대해 영상을 만들었으니 우선 이것을 참고하시기 바랍니다. kzbin.info/www/bejne/bp68YqOBjJegbc0

[@user-fz7ys7cv3c]

잘보고갑니다

[@user-in5gx2lm4e]

7:50초에 나오는 3-way handshake과정 그림에서 SYN(1000)은 Sequence Number가 1000임을 의미하는 것이고 ACK(1000)은 Acknowledgment Number가 1001임을 의미하는 것인가요? TCP flag로서 syn과 헷갈려서 질문하게 되었습니다

[@nullnull_not_eq_null]

ACK가 1000 + 1이 되는 이유는 상대가 보내준 SEQ 번호가 1000임을 확인시켜주기 위한 용도입니다. 참고하시기 바랍니다. ^^

[@django3861]

네트워크 기초 이론 스터디 26강 완강 / 5월 16일 / 헬스장

[@user-sf8mp8qo7h]

아니었군요 그냥 확인 하는거지 감사합니다

[@nullnull_not_eq_null]

TCP 연결은 Virtual circuit이라고 하지요. 논리적 연결...즉, 그렇다고 소프트웨어적으로 서로 합의 하는 것이 전부입니다.

[@gudrbe]

좋은 강의 감사합니다! 내용을 정리중인데, 클라이언트가 서버에 연결하고자할때 syn 플래그와 시퀀스 번호가 포함된 tcp세그먼트를 보낸다고 하면 맞는 말일까요??

[@nullnull_not_eq_null]

네, 맞습니다. 제대로 이해하셨습니다. ^^

[@gudrbe]

@@nullnull_not_eq_null 답변 감사합니다!😄

[@tkaehfdl99]

강사님 강의 진행하실때 사용하시는 툴이 뭔가요? 꽤 편해 보이는데요 ….

[@nullnull_not_eq_null]

Microsoft Whiteboard 입니다. Mac에 비해 아쉬운 점도 있지만 저는 만족하며 잘 쓰고 있습니다. ^^;;

[@user-yb1rl6wq5i]

안녕하세요. TCP 연결에서의 3-way handshake의 순서는 IP 계층의 라우팅을 한 뒤 일어나는지와, 송신할 때와 수신할 때 그 순서가 바뀌지 않는지 궁금해서 댓글 남깁니다!

[@nullnull_not_eq_null]

음...'IP계층의 라우팅 뒤'라는 말의 의미를 모르겠습니다. 다만 짐작으로 답을 드리자면... 모든 패킷은 라우터의 라우팅 과정을 거쳐 목적지에 도달합니다. 연결과정에서도 이는 다르지 않습니다. 그리고 시퀀스 번호는 송신하는 세그먼트의 바이트 크기만큼 계속 증가합니다. 참고하시기 바랍니다.

[@user-yb1rl6wq5i]

@@nullnull_not_eq_null 제가 이해가 많이 부족한 상태에서 질문을 드린거 같아 죄송합니다. 염치 불구하고 정정하여 다시 질문 드리고 싶습니다! 3-way handshake 가 완료 되면 TCP계층의 '논리적 연결' 이 되었다고 이해를 하였는데 그게 맞는지요. 그리고 3-way handshake 과정에서 SYN-ACK 패킷의 이동은 결국 물리계층에서 전기신호로 변환 되어 인터넷을 통해 주고 받는게 맞는지 궁금합니다 교수님.

[@nullnull_not_eq_null]

@@user-yb1rl6wq5i 네, 맞습니다. TCP의 연결은 논리적 연결이며 물리적 연결과 다릅니다. 그리고 굳이 3 way handshake 과정이 아니더라도 모든 패킷은 결국 물리적 신호로 변경되어 전달됩니다. 전기 신호만 있는 것이 아니라 물리 회선이 광케이블이라면 빛의 신호로 변경되어 전달된다고 할 수 있겠습니다. 마지막으로...죄송할 일이 아닙니다. 모르면 질문해야 합니다. 아무리 창피하고 욕을 좀 먹게 되더라도 해야 합니다. :)

[@user-yb1rl6wq5i]

@@nullnull_not_eq_null 며칠동안 저 개념이 햇갈렸는데 드디어 정리가 되네요 ㅠㅠ 좋은 강의와 답변에 감사드립니다!

[@whistle_missile2]

보안성이 없다는게 syn플러드 공격같은걸 말씀하시는것 같은데 syn쿠키로 막을 수 있지 않나요?

[@nullnull_not_eq_null]

보안성이 없다는 것은 기밀성 및 무결성이 보장되지 않는다는 의미 입니다. 즉 TCP는 암호화 관련 Spec이 없습니다. 따라서 VPN을 적용하든 SSL을 적용하든 대책을 세워야 하고 패킷 헤더를 임의 변조하더라도 막을 방법이 없습니다. 그리고 SYN과 Cookie는 관련이 없습니다. Cookie는 HTTP에서 언급되는 것으로 4계층 TCP와 아무 관련이 없습니다. 참고하시기 바랍니다. ^^

[@VirusPropWar]

글쎄요, 워낙 오래전에 일로 하던 내용이라 기억이 가물가물하지만 듣다가 보니 이상해서요. TCP는 IP의 비연결성 문제를 극복하기 위해 만들어지 계층인데요. 시퀀스를 이용해서 통신도중 소실된 패킷이 있나 없나 확인을 해줍니다. 만약 소실됐다면 해당 시퀀스 번호의 패킷 재전송을 요구하지요. 로컬과 리모트의 TCP 계층에서 이 부분을 처리해주기 때문에 TCP를 이용하는 프로세스들은 말씀하신 것처럼 소켓을 오픈하고 파일처럼 사용할 수 있습니다. 그래서 연결지향 서비스라고 하는 겁니다. UDP나 IP는 이 시퀀스 넘버가 없어요. 중간에 소실되면 그 걸로 그냥 끝나는 겁니다. 비디오나 오디오는 패킷소실이 생겨도 그다지 문제가 되지 않기 때문에. UDP를 사용합니다. 멀티캐스트도 마찬가지구요. 3way handshake완 상관없어요. 원래는 SYN, ACK를 로컬, 리모트에서 각각 해줘야하는 절차를 줄이기 위해서 3way handshake를 하는 겁니다. 커맨드에서 netstat -n을 하시면 TCP는 계속해서 연결을 유지하고 있어요. UDP는 없습니다. 마치 전화와 우편 서비스의 차이점과 비슷합니다. TCP연결은 착각이 아니라, 프로세스 쪽에서는 전화회선과 같은 역할을 해줍니다. 물론 저는 개발자는 아니기 때문에 선생님과 보는 시각이 다를 수 있음을 말씀드립니다.

[@nullnull_not_eq_null]

음...제가 굳이 '착각' 이라는 조금은 과장된 표현을 사용했는지에 대해서는 영상에 어느 정도 표현되었으리라 생각합니다. 제 주장을 뒷받침하는 근거로 저는 NAT기반 공유기를 말씀드리고 싶습니다. 아시겠지만 공유기가 어딘가에 접속하는 것이 아니라 공유기 내부 호스트가 원격 서버에 접속하는 것이죠. 문제는 리모트 서버는 공유기가 사용중인 IP주소 호스트와 연결됐다고 판단하다는 점입니다. 또한 각종 보안 장치들이 개입하기 시작하면 연결이라는 결론은 실제 End-point와는 점점 더 거리가 멀어지기도 합니다. 의견 감사드리며 이 견해에 대해서도 의견 주시면 고맙겠습니다. ^^

[@VirusPropWar]

@@nullnull_not_eq_null 아마 NAT, PAT를 말씀하시는 것 같은데, TCP는 영향을 받지 않습니다. 내부 호스트와 공유기를 통한 외부 호스트간의 TCP 세션은 무결성을 보장받습니다.

[@nullnull_not_eq_null]

@@VirusPropWar 우선 TCP 세션은 보안성이 없습니다. 즉, 위변조가 가능하다는 의미이며 정보보안 3원칙 중 무결성의 원칙을 보장받지 못합니다. 이는 IP주소도 마찬가지 입니다. 이 연장선에서 연결의 두 통신 주체 중 하나는 자신이 연결했다고 판단하는 호스트가 실제로는 전혀 다른 주체일 수 있습니다. 그리고 이런 변조가 가능하기 때문에 NAT도 구현이 가능하고요. 해서 이런 저런 상황 + 보안 등을 고려했을 때 저는 TCP virtual circuit이 말 그대로 실체가 없는 착각이라 보는 것입니다. 의견 감사합니다. ^^ 그리고 이 글들을 보는 다른 분들께 매우 중요한 참고가 되리라 확신합니다. ^^

[@VirusPropWar]

@@nullnull_not_eq_null 사실 통신(전자통신, 정보통신)은 제 전문분야라 선생님이 어떤 말씀을 하셨나 궁금했을 뿐입니다. 말씀드렸던 것처럼 저는 코딩을 다시 연마하는 게 목적이니 다른 분야를 찾아보겠습니다. 도움 말씀 감사합니다

[@user-tk9uj2sn7w]

@@VirusPropWar두분 다 같은 말씀하고 계시는데 댓쓴분은 TCP라는 프로토콜 동작 자체에서의 무결성을 말씀하시고, 채널주인장님은 해킹 관점에서의 무결성을 말씀하시는듯요.

[@lasercho4338]

음..... 연결은.... 착각이다......

[@nullnull_not_eq_null]

잘 기억해두면 TCP session hijecking까지 한 방에 끝납니다!

[@user-ot6be2qh8v]

32bit면 4byte 아닌가요? 40억(4billion, 4Giga)하고 순간 헷갈리신 듯

[@nullnull_not_eq_null]

32비트 시스템으로 제어 가능한 메모리크기는 4GB 맞습니다.

[@upzerg]

메모리는 바이트 단위 접근으로 이루어지기 때문에 32비트를 가지고 메모리 접근 표현의 가능한 경우의 수는 2^32바이트 = 4GB입니다 ㅎㅎ