아... 오늘 강의를 들었더니 드디어 "연결"이라는 개념 자체가 좀 와닿네요. 역대급 강의가 정말 많은 것 같습니다 선생님 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 번호를 버퍼에 저장한다. 원하는 곳으로 데이터를 전송할 때 해당 버퍼를 들여다 보고 버퍼에 들어있는 값들을 헤더에 써서 전송한다.
안녕하세요 교수님, 4년전 군대에서 컴퓨터에 관심이 생겨 교수님 C강의로 프로그래밍에 처음 입문했는데, 시간이 흘러 벌써 해외 전문대에서 편입 준비를 마치고 컴퓨터과학과로 원서지원을 마무리 했습니다 ㅎㅎ 교수님이 알려주신 포인터와 메모리 개념은 아직까지도 모든 과제든 공부에 도움이 되는 것을 보면서 처음 공부 시작이 정말 좋았다는 생각을 매번 안할수가 없었던거 같네요 양질의 강의 올려주셔서 정말 감사하고 또 앞으로도 명강의 수강할 수 있었으면 좋겠네요 :D 항상 건강하시고 응원합니다!
안녕하세요. 제공해주신 동영상 너무 잘봤습니다. 제가 이 '연결 지향'이라는 말을 올바르게 이해하고 있는지 여쭙고자 댓글을 남깁니다. 저는 최근에 서버 프로그래밍에 입문했는데, 이 연결이라는 말이 무엇인지 많이 고민하고 있었습니다. 개인적으로는 연결이라고 하면 현실에서 호스를 잇고 그리로 물이 흘러다니는 모습이 연상되는데, 네트워크 환경에서의 송수신은 이런 식으로 동작하지 않는다고 생각하여 큰 괴리를 느꼈기 때문입니다. 그럼에도 연결이라는 표현이 왜 쓰이는지 이해해보고자 인터넷에 기술된 여러 아티클을 읽고 내린 제 나름대로의 결론은, 'TCP 소켓의 경우 수신자와 발신자가 한 번 통신이 이루어지고 나면, 데이터 송수신 히스토리 (시퀀스 넘버가 이에 해당하겠습니다), IP와 포트를 메모리에 저장해둠으로써 세션을 유지한다라는 점에서 연결 지향이라는 표현을 사용한다.' 였습니다. 반대로 UDP의 경우엔 이러한 데이터 송수신 히스토리, 리모트의 IP는 메모리에 유지하지 않는다는 점에서 비연결 지향으로 분류된다고 이해했습니다. 혹시 틀리거나 보충할만한 부분이 있으시면 부디 조언 부탁드리겠습니다!
UDP는 IP와 별개로 4계층 프로토콜입니다. 원격지 IP에 대한 정보는 이미 3계층에 속해 있고 OS수준에서 메모리에 저장해 가지고 있습니다. 이를 '연결'이라는 개념과 잇는 것은 큰 의미가 없겠습니다. 그 외 나머지는 영상의 내용이 이미 들어 있는 것이라 하겠습니다. 감사합니다. :)
안녕하세요 대표님!! 항상 잘 듣고 있습니다~~ 학습 중 궁금한 부분이 있어서 질문드립니다! 많은 글들에서 SYN를 만들 때 랜덤 값을 지정하는 이유를 다음과 같이 설명합니다. “난수가 아닌 순차적인 number가 전송된다면 서버가 이전의 커넥션에서 오는 패킷으로 인식할 수 있다. 이러한 가능성을 줄이기 위해 난수로 만든다.” 이 말이 이해가 잘 가지 않는데 맞는 설명일까요? 클라이언트와는 다르게 서버는 포트 하나만으로 요청을 받기 때문에 소켓을 구성할 때 (클라이언트 ip, 클라이언트 port, 서버 ip, 서버 port)와 같은 정보를 통해 수많은 클라이언트들을 구분하고 통신을 하겠구나라고 이해했습니다. 즉 이러한 수많은 소켓들을 하나씩 listening 하면서 서버가 어떤 클라이언트로부터 온 요청인지 특정지을 수 있다고 생각했습니다. 하지만 위의 설명대로라면 “서버로 들어오는 모든 패킷에 대해 SYN를 통해서만 클라이언트를 구분한다”라고 결론이 나서 의문이 들었습니다. 위의 난수에 대한 설명은 소켓 생성 전, 3-way handshaking 과정에서만 해당하는 내용일까요? 아니면 제가 완벽히 잘못 이해하고 있는걸까요.. 😭
Seq. number를 난수로 만들어서 예측을 피해야 하는 이유는 TCP Session hijacking attack 때문입니다. 제가 '연결은 착각'이라는 주장을 반복하는 이유는 연결의 판단 근거에 Seq number가 사용되기 때문이기도 합니다. 누군가 두 End-point간의 TCP seq number를 정확히 예측해서 맞춰내고 그에 따른 응답을 할 수 있다면 TCP session을 가로챌 수 있습니다. 그리고 서버는 특정 포트 번호하나로 연결을 받지만 세션 하나를 식별할 때는 원격지 IP + Port 번호를 조합해 식별하므로 문제가 없습니다. 여기서 TCP seq number는 결합해서 생각할 필요가 없습니다. 단순 식별의 문제와 TCP session의 문제는 분리해 생각하는 것이 맞겠습니다. 참고하시기 바랍니다.
@@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 계층 암호화라 소용없을 것 같습니다. 간단한 솔루션에 대한 키워드를 알려주실 수 있으실까요!
음...'IP계층의 라우팅 뒤'라는 말의 의미를 모르겠습니다. 다만 짐작으로 답을 드리자면... 모든 패킷은 라우터의 라우팅 과정을 거쳐 목적지에 도달합니다. 연결과정에서도 이는 다르지 않습니다. 그리고 시퀀스 번호는 송신하는 세그먼트의 바이트 크기만큼 계속 증가합니다. 참고하시기 바랍니다.
@@nullnull_not_eq_null 제가 이해가 많이 부족한 상태에서 질문을 드린거 같아 죄송합니다. 염치 불구하고 정정하여 다시 질문 드리고 싶습니다! 3-way handshake 가 완료 되면 TCP계층의 '논리적 연결' 이 되었다고 이해를 하였는데 그게 맞는지요. 그리고 3-way handshake 과정에서 SYN-ACK 패킷의 이동은 결국 물리계층에서 전기신호로 변환 되어 인터넷을 통해 주고 받는게 맞는지 궁금합니다 교수님.
@@태영-c5f 네, 맞습니다. TCP의 연결은 논리적 연결이며 물리적 연결과 다릅니다. 그리고 굳이 3 way handshake 과정이 아니더라도 모든 패킷은 결국 물리적 신호로 변경되어 전달됩니다. 전기 신호만 있는 것이 아니라 물리 회선이 광케이블이라면 빛의 신호로 변경되어 전달된다고 할 수 있겠습니다. 마지막으로...죄송할 일이 아닙니다. 모르면 질문해야 합니다. 아무리 창피하고 욕을 좀 먹게 되더라도 해야 합니다. :)
안녕하세요 교수님 본 강의에서 시퀀스넘버를 이야기 해주시면서 2^32는 4GB다라고 말씀 해주셨는데 시퀀스넘버는 단순 조립순서(퍼즐)인거지 이게 4GB랑 크게 연관점이 있는건가요 ? 아니면 단순하게 팁으로서 설명 해주신건가요 ? 추가로 1.시퀀스넘버가 실제 4GB가 넘을 수 있는건가요? 2.시퀀스넘버는 TCP소켓이 계속 유지되고있으면 증가하는건가요? (HTTP 커넥션은 유지 되어 있는 상태) 3.64bit os를 지원한다면 세그먼트의 사이즈도 64bit로 증가하는건가요?
조립 순서입니다. 하지만 송신한 바이트 수만큼 증가하므로 이 번호의 증가량을 계산해 송신한 데이터 량을 측정할 수 있습니다. 시퀀스 번호는 감소할 수 없습니다. 다만 4GB(32비트 한계)를 넘어가면 범위를 넘어가 0위치로 되돌아 갑니다. 그러나 증가 값 계산은 지속할 수 있으므로 넘어도 문제는 없습니다. 끝으로 운영체제와는 무관합니다.
보안성이 없다는 것은 기밀성 및 무결성이 보장되지 않는다는 의미 입니다. 즉 TCP는 암호화 관련 Spec이 없습니다. 따라서 VPN을 적용하든 SSL을 적용하든 대책을 세워야 하고 패킷 헤더를 임의 변조하더라도 막을 방법이 없습니다. 그리고 SYN과 Cookie는 관련이 없습니다. Cookie는 HTTP에서 언급되는 것으로 4계층 TCP와 아무 관련이 없습니다. 참고하시기 바랍니다. ^^
현대 네트워크 환경에서 TCP 헤더의 Sequence Number 필드는 MAX 값까지 얼마안가 금방 차게됩니다. 이 경우 보통 0으로 다시 복귀하게 되지만, 여러가지 사유로 그렇게 되지 않을 수도 있습니다. 이 경우 네트워크 장애가 발생할 수 있을까요 ^^? 발생한다면 어떤 현상으로 관측될까요? 해당 장애가 발생한다면 이를 어떻게 진단하고 해결할까요 ^^?
Seq 번호는 32비트 부호가 없는 정수형입니다. 따라서 4GB까지가 한계입니다. 한 TCP 세션에서 4GB이상 통신하면 Seq 번호는 다시 0으로 돌아옵니다. 그리고 이것은 장애가 아닙니다. '그렇게 되지 않는 경우'는 어떤 경우일까요??? 아마도 VPN 같은 곳에서 정책적으로 데이터 송/수신량에 대한 제한을 두는 경우가 있는데 그 경우를 생각하신 것 같습니다. 대표적인 TCP 장애에 대해 영상을 만들었으니 우선 이것을 참고하시기 바랍니다. ruclips.net/video/8mY1pKW2m7k/видео.html
![[1부] 프로토콜 표준 스펙에서 정의한 Socket(소켓), Port(포트), TCP connection(연결) 개념](/img/1.gif)
아... 오늘 강의를 들었더니 드디어 "연결"이라는 개념 자체가 좀 와닿네요. 역대급 강의가 정말 많은 것 같습니다 선생님
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 번호를 버퍼에 저장한다.
원하는 곳으로 데이터를 전송할 때 해당 버퍼를 들여다 보고 버퍼에 들어있는 값들을 헤더에 써서 전송한다.
열공 모드로 달리시는 군요! 좋은 결과로 이어지기를 응원 합니다. 감사합니다. ^^
안녕하세요 교수님, 4년전 군대에서 컴퓨터에 관심이 생겨 교수님 C강의로 프로그래밍에 처음 입문했는데,
시간이 흘러 벌써 해외 전문대에서 편입 준비를 마치고 컴퓨터과학과로 원서지원을 마무리 했습니다 ㅎㅎ
교수님이 알려주신 포인터와 메모리 개념은 아직까지도 모든 과제든 공부에 도움이 되는 것을 보면서
처음 공부 시작이 정말 좋았다는 생각을 매번 안할수가 없었던거 같네요
양질의 강의 올려주셔서 정말 감사하고 또 앞으로도 명강의 수강할 수 있었으면 좋겠네요 :D
항상 건강하시고 응원합니다!
전공자가 될 사람이라면 메모리 디버깅은 할 줄 알아야 합니다. 감사하게도 제 생각이 맞다는 것을 다시 한 번 확인해주셨네요. ^^
열공하시고 좋은 성과 거두시기 바랍니다. 건투를 빕니다!
해킹당했는지 도대체 뭐가 문제인지 찾다가 영상보고 답을 찾았네요~감사합니다
부디 큰 피해는 없으시기 바랍니다. 건투를 빕니다!
연결은? 착각이다 , TCP연결은 3way handshake로 이루어 지는데 , 이것은 seq번호 교환 + mss교환 + 정책(혼잡제어 관련) 교환 (요즘은 SACK사용) 이다 , 이것에는 보안성이 없다는것에 명심하자!!
항상 좋은 강의 감사드립니다!
네, 착각입니다. 즉, 실제와 다를 수 있다는 것이죠. 열공하세요~~~! ^^
대표님! 강의를 다시 시청하는 중에 질문이 생겨 댓글을 남깁니다.
3-way handshake과정에서 TCP연결을 위해 사용되는 패킷은 payload가 없으며 TCP헤더의 설정값들의 변화(Sequence Number등)만을 인지하고자 주고받는 패킷인가요?
네, 데이터를 주고 받는 것은 아니므로 Payload가 없습니다. 참고하시기 바랍니다. ^^
7:50초에 나오는 3-way handshake과정 그림에서 SYN(1000)은 Sequence Number가 1000임을 의미하는 것이고 ACK(1000)은 Acknowledgment Number가 1001임을 의미하는 것인가요? TCP flag로서 syn과 헷갈려서 질문하게 되었습니다
ACK가 1000 + 1이 되는 이유는 상대가 보내준 SEQ 번호가 1000임을 확인시켜주기 위한 용도입니다. 참고하시기 바랍니다. ^^
와 진짜 도움 너무 많이 되네요! 감사합니다!
도움이 되셨다니 다행입니다.
안녕하세요. 제공해주신 동영상 너무 잘봤습니다.
제가 이 '연결 지향'이라는 말을 올바르게 이해하고 있는지 여쭙고자 댓글을 남깁니다.
저는 최근에 서버 프로그래밍에 입문했는데, 이 연결이라는 말이 무엇인지 많이 고민하고 있었습니다.
개인적으로는 연결이라고 하면 현실에서 호스를 잇고 그리로 물이 흘러다니는 모습이 연상되는데, 네트워크 환경에서의 송수신은 이런 식으로 동작하지 않는다고 생각하여 큰 괴리를 느꼈기 때문입니다.
그럼에도 연결이라는 표현이 왜 쓰이는지 이해해보고자 인터넷에 기술된 여러 아티클을 읽고 내린 제 나름대로의 결론은, 'TCP 소켓의 경우 수신자와 발신자가 한 번 통신이 이루어지고 나면, 데이터 송수신 히스토리 (시퀀스 넘버가 이에 해당하겠습니다), IP와 포트를 메모리에 저장해둠으로써 세션을 유지한다라는 점에서 연결 지향이라는 표현을 사용한다.' 였습니다.
반대로 UDP의 경우엔 이러한 데이터 송수신 히스토리, 리모트의 IP는 메모리에 유지하지 않는다는 점에서 비연결 지향으로 분류된다고 이해했습니다.
혹시 틀리거나 보충할만한 부분이 있으시면 부디 조언 부탁드리겠습니다!
UDP는 IP와 별개로 4계층 프로토콜입니다. 원격지 IP에 대한 정보는 이미 3계층에 속해 있고 OS수준에서 메모리에 저장해 가지고 있습니다. 이를 '연결'이라는 개념과 잇는 것은 큰 의미가 없겠습니다. 그 외 나머지는 영상의 내용이 이미 들어 있는 것이라 하겠습니다. 감사합니다. :)
안녕하세요 대표님!! 항상 잘 듣고 있습니다~~ 학습 중 궁금한 부분이 있어서 질문드립니다!
많은 글들에서 SYN를 만들 때 랜덤 값을 지정하는 이유를 다음과 같이 설명합니다. “난수가 아닌 순차적인 number가 전송된다면 서버가 이전의 커넥션에서 오는 패킷으로 인식할 수 있다. 이러한 가능성을 줄이기 위해 난수로 만든다.” 이 말이 이해가 잘 가지 않는데 맞는 설명일까요?
클라이언트와는 다르게 서버는 포트 하나만으로 요청을 받기 때문에 소켓을 구성할 때 (클라이언트 ip, 클라이언트 port, 서버 ip, 서버 port)와 같은 정보를 통해 수많은 클라이언트들을 구분하고 통신을 하겠구나라고 이해했습니다. 즉 이러한 수많은 소켓들을 하나씩 listening 하면서 서버가 어떤 클라이언트로부터 온 요청인지 특정지을 수 있다고 생각했습니다.
하지만 위의 설명대로라면 “서버로 들어오는 모든 패킷에 대해 SYN를 통해서만 클라이언트를 구분한다”라고 결론이 나서 의문이 들었습니다. 위의 난수에 대한 설명은 소켓 생성 전, 3-way handshaking 과정에서만 해당하는 내용일까요? 아니면 제가 완벽히 잘못 이해하고 있는걸까요.. 😭
Seq. number를 난수로 만들어서 예측을 피해야 하는 이유는 TCP Session hijacking attack 때문입니다. 제가 '연결은 착각'이라는 주장을 반복하는 이유는 연결의 판단 근거에 Seq number가 사용되기 때문이기도 합니다. 누군가 두 End-point간의 TCP seq number를 정확히 예측해서 맞춰내고 그에 따른 응답을 할 수 있다면 TCP session을 가로챌 수 있습니다.
그리고 서버는 특정 포트 번호하나로 연결을 받지만 세션 하나를 식별할 때는 원격지 IP + Port 번호를 조합해 식별하므로 문제가 없습니다. 여기서 TCP seq number는 결합해서 생각할 필요가 없습니다. 단순 식별의 문제와 TCP session의 문제는 분리해 생각하는 것이 맞겠습니다. 참고하시기 바랍니다.
@@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 계층 암호화라 소용없을 것 같습니다. 간단한 솔루션에 대한 키워드를 알려주실 수 있으실까요!
잘봤습니다
시청해 주셔서 감사드립니다.
3way hand shake 번역하실때 빵 터졌네요 ㅋㅋㅋㅋ 세방향 악수하기?
전문용어라는 것 번역해보면 꽤 웃길 때가 있습니다. Tunnel도...^^;;;
3번 패킷을 주고받는거니 3번 악수하기정도 아닐까요?
네트워크 기초 이론 스터디
26강 완강 / 5월 16일 / 헬스장
잘들었습니다.ㅎ
잊지마세요. 연결은 객관성 없는 자기 판단에 불과합니다. 열공하세요~~~! ^^
안녕하세요. TCP 연결에서의 3-way handshake의 순서는 IP 계층의 라우팅을 한 뒤 일어나는지와, 송신할 때와 수신할 때
그 순서가 바뀌지 않는지 궁금해서 댓글 남깁니다!
음...'IP계층의 라우팅 뒤'라는 말의 의미를 모르겠습니다. 다만 짐작으로 답을 드리자면...
모든 패킷은 라우터의 라우팅 과정을 거쳐 목적지에 도달합니다. 연결과정에서도 이는 다르지 않습니다. 그리고 시퀀스 번호는 송신하는 세그먼트의 바이트 크기만큼 계속 증가합니다. 참고하시기 바랍니다.
@@nullnull_not_eq_null 제가 이해가 많이 부족한 상태에서 질문을 드린거 같아 죄송합니다.
염치 불구하고 정정하여 다시 질문 드리고 싶습니다! 3-way handshake 가 완료 되면 TCP계층의 '논리적 연결' 이 되었다고 이해를 하였는데 그게 맞는지요.
그리고 3-way handshake 과정에서 SYN-ACK 패킷의 이동은 결국 물리계층에서 전기신호로 변환 되어 인터넷을 통해 주고 받는게 맞는지 궁금합니다 교수님.
@@태영-c5f 네, 맞습니다. TCP의 연결은 논리적 연결이며 물리적 연결과 다릅니다. 그리고 굳이 3 way handshake 과정이 아니더라도 모든 패킷은 결국 물리적 신호로 변경되어 전달됩니다. 전기 신호만 있는 것이 아니라 물리 회선이 광케이블이라면 빛의 신호로 변경되어 전달된다고 할 수 있겠습니다. 마지막으로...죄송할 일이 아닙니다. 모르면 질문해야 합니다. 아무리 창피하고 욕을 좀 먹게 되더라도 해야 합니다. :)
@@nullnull_not_eq_null 며칠동안 저 개념이 햇갈렸는데 드디어 정리가 되네요 ㅠㅠ 좋은 강의와 답변에 감사드립니다!
안녕하세요 교수님 본 강의에서 시퀀스넘버를 이야기 해주시면서 2^32는 4GB다라고 말씀 해주셨는데 시퀀스넘버는 단순 조립순서(퍼즐)인거지 이게 4GB랑 크게 연관점이 있는건가요 ? 아니면 단순하게 팁으로서 설명 해주신건가요 ?
추가로
1.시퀀스넘버가 실제 4GB가 넘을 수 있는건가요?
2.시퀀스넘버는 TCP소켓이 계속 유지되고있으면 증가하는건가요? (HTTP 커넥션은 유지 되어 있는 상태)
3.64bit os를 지원한다면 세그먼트의 사이즈도 64bit로 증가하는건가요?
조립 순서입니다. 하지만 송신한 바이트 수만큼 증가하므로 이 번호의 증가량을 계산해 송신한 데이터 량을 측정할 수 있습니다. 시퀀스 번호는 감소할 수 없습니다. 다만 4GB(32비트 한계)를 넘어가면 범위를 넘어가 0위치로 되돌아 갑니다. 그러나 증가 값 계산은 지속할 수 있으므로 넘어도 문제는 없습니다.
끝으로 운영체제와는 무관합니다.
좋은 강의 감사합니다!
내용을 정리중인데,
클라이언트가 서버에 연결하고자할때 syn 플래그와 시퀀스 번호가 포함된 tcp세그먼트를 보낸다고 하면 맞는 말일까요??
네, 맞습니다. 제대로 이해하셨습니다. ^^
@@nullnull_not_eq_null 답변 감사합니다!😄
아니었군요
그냥 확인 하는거지
감사합니다
TCP 연결은 Virtual circuit이라고 하지요. 논리적 연결...즉, 그렇다고 소프트웨어적으로 서로 합의 하는 것이 전부입니다.
잘보고갑니다
보안성이 없다는게 syn플러드 공격같은걸 말씀하시는것 같은데 syn쿠키로 막을 수 있지 않나요?
보안성이 없다는 것은 기밀성 및 무결성이 보장되지 않는다는 의미 입니다. 즉 TCP는 암호화 관련 Spec이 없습니다. 따라서 VPN을 적용하든 SSL을 적용하든 대책을 세워야 하고 패킷 헤더를 임의 변조하더라도 막을 방법이 없습니다.
그리고 SYN과 Cookie는 관련이 없습니다. Cookie는 HTTP에서 언급되는 것으로 4계층 TCP와 아무 관련이 없습니다. 참고하시기 바랍니다. ^^
강사님 강의 진행하실때 사용하시는 툴이 뭔가요? 꽤 편해 보이는데요 ….
Microsoft Whiteboard 입니다. Mac에 비해 아쉬운 점도 있지만 저는 만족하며 잘 쓰고 있습니다. ^^;;
음..... 연결은.... 착각이다......
잘 기억해두면 TCP session hijecking까지 한 방에 끝납니다!
32bit면 4byte 아닌가요? 40억(4billion, 4Giga)하고 순간 헷갈리신 듯
32비트 시스템으로 제어 가능한 메모리크기는 4GB 맞습니다.
메모리는 바이트 단위 접근으로 이루어지기 때문에 32비트를 가지고 메모리 접근 표현의 가능한 경우의 수는 2^32바이트 = 4GB입니다 ㅎㅎ
현대 네트워크 환경에서 TCP 헤더의 Sequence Number 필드는 MAX 값까지 얼마안가 금방 차게됩니다.
이 경우 보통 0으로 다시 복귀하게 되지만, 여러가지 사유로 그렇게 되지 않을 수도 있습니다.
이 경우 네트워크 장애가 발생할 수 있을까요 ^^? 발생한다면 어떤 현상으로 관측될까요? 해당 장애가 발생한다면 이를 어떻게 진단하고 해결할까요 ^^?
Seq 번호는 32비트 부호가 없는 정수형입니다. 따라서 4GB까지가 한계입니다. 한 TCP 세션에서 4GB이상 통신하면 Seq 번호는 다시 0으로 돌아옵니다. 그리고 이것은 장애가 아닙니다. '그렇게 되지 않는 경우'는 어떤 경우일까요???
아마도 VPN 같은 곳에서 정책적으로 데이터 송/수신량에 대한 제한을 두는 경우가 있는데 그 경우를 생각하신 것 같습니다.
대표적인 TCP 장애에 대해 영상을 만들었으니 우선 이것을 참고하시기 바랍니다.
ruclips.net/video/8mY1pKW2m7k/видео.html