TCP 기본

훈수/저작권 관련 지적 환영합니다 - 댓글 또는 audgnssweet@naver.com

 

TCP

---

TCP

전송 제어 프로토콜은 인터넷 프로토콜 스위트의 핵심 프로토콜 중 하나로, IP와 함께 TCP/IP라는 명칭으로도 널리 불린다. TCP는 근거리 통신망이나 인트라넷, 인터넷에 연결된 컴퓨터에서 실행되는 프로그램 간에 일련의 옥텟을 안정적으로, 순서대로, 에러없이 교환할 수 있게 한다 -위키백과-

TCP는 OSI 7 계층(링크)중 4 계층인 전송 계층에 속하는 프로토콜로,

연결 지향형 프로토콜입니다.

UDP와 달리 데이터 전송의 신뢰성을 확보할 수 있습니다.

---

1. 데이터가 목적지까지 전달되었는지 확인
   • ACK (확인 + 다음 받을 패킷의 SEQ NUM)
2. 데이터가 순서대로 전달되었는지 확인
   • SEQ (이번에 보내는 byte SEQ NUM)
3. 목적지의 버퍼가 꽉 차서 데이터가 버려지는 것을 방지
   • 흐름 제어
4. 네트워크가 혼잡하면 보내는 데이터의 양을 조절
   • 혼잡 제어

---

---

TCP 헤더

---

출처: https://m.blog.naver.com/PostView.nhn?blogId=o_olool&logNo=220047644045&proxyReferer=https:%2F%2Fwww.google.com%2F

 

1. Source Port, Destination Port
   -> 보내는 쪽의 포트번호, 받는 쪽의 포트번호
2. Sequence Number
   -> 데이터의 순서가 올바른지 확인 + (보안적인 이슈)
   -> 바이트 스트림으로 데이터를 전송하기 때문에, 바이트 시퀀스 중 가장 빠른 번호 할당
3. Acknowledgement Number
   -> 데이터가 도착했는지 확인
   -> 다음에 전송받을 데이터의 SEQ NUM이 들어간다.
4. TCP Flags
   -> 세그먼트의 기능을 표시 (SYN, ACK 등)
5. Window
   -> 수신 윈도우의 크기를 알려줌  (흐름 제어 위해)
6. Checksum
   -> 데이터의 무결성 검증을 위함

---

---

TCP 연결, 해제

---

연결

3-way-handshake를 통한 연결

TCP는 연결 후 동기화가 된 상태에서 데이터를 주고받습니다.

해당 과정은 연결을 생성하는 과정입니다.

출처: 학부 수업

클라이언트	서버
SYN 패킷을 보낸다. 이 때, 헤더의 SEQ에 random한 번호를 할당하여 보낸다. (위 그림에서는 8000)
	SYN에 대한 ACK + SYN 패킷을 보낸다. 이 때, 마찬가지로 헤더의 SEQ에 random한 번호를 할당하여 보낸다. ACK에는 ACK번호(클라이언트쪽에서 보낸 SEQ번호 + 1한 값)을 보내는데, 이유는 ACK번호가 "다음에 받을 바이트 스트림 번호"이기 때문이다. -> 이미 8000번까지는 받았기 떄문에 + SYN 패킷의 크기가 1이기 때문에
SYN에 대한 ACK 패킷을 보낸다. 이 때, 다음 보낼 바이트 번호가 8001번이었기 때문에 SEQ는 8001, ACK는 다음 받을 바이트 번호이기 떄문에 15001이다 -> 이미 15000까지는 받았기 때문에

---

해제

연결과 비슷한 과정을 거쳐서 해제도 일어납니다.

 

 

연결 설정과 다른 점은,

서버 쪽에서 ACK와 FIN을 동시에 보내지 않을 수도 있다(보낼 수도 있다)는 것입니다.

서버 쪽에서 마무리해야 할 작업이 있다면 마무리를 하고 준비가 되었을 때 FIN 요청을 보내게 됩니다.

 

SYN이 FIN으로 바뀌었을 뿐이므로 자세한 설명은 생략하겠습니다.

---

---

흐름 제어

---

데이터를 보낼 때, 받는 쪽에서 공간이 넘쳐나고 보내는 쪽에서 느리게 보내는 것은 큰 문제가 되지는 않습니다.

느릴 뿐이지 데이터는 전송되기 때문입니다.

 

그러나 보내는 쪽에서 받는 쪽이 감당할 수 없을 만큼 데이터를 보내게 된다면 결국 받지 못하고 버리게 되고, 신뢰성 있는 전송(TCP의 목표)이 지켜지지 않습니다.

이에 받는 쪽의 상태를 체크하면서 데이터를 보내는 것이 흐름 제어의 기본 개념입니다.

---

송신 버퍼

수신 측에 전송할 데이터를 보관하는 공간

수신 버퍼

송신 측에서 받은 데이터를 보관하는 공간

 

 

---

송신 윈도우

수신 측의 ACK를 고려하지 않고, 한 번에 보낼 수 있는 바이트 크기

수신 윈도우

한 번에 저장할 수 있는 바이트 크기

 

윈도우의 크기는

윈도우 알고리즘과 기타 여러 변수들에 의해서 결정됩니다.

수신 버퍼의 여유공간을 체크하면서(윈도우 통해) 적당한 양의 데이터를 보내야 신뢰성 있는 전송이 되겠죠?

 

---

---

실습

---

1. wireshark를 사용했습니다.

2. vmware 가상 머신 위에 설치한 ubuntu 위에서 터미널 두 개를 띄워서 테스트했습니다. (같은 Local)

3. 127.0.0.1은 클라이언트, 127.0.0.3은 서버입니다.

 

윗부분이 3-way-handshake를 통한 연결 설정,

중간 부분이 데이터를 주고받는 과정,

아랫부분이 연결을 해제하는 과정입니다.

실제로 연결과 해제가 이런 방식으로 일어난다는 것을 알 수 있었습니다.

 

또한 중간의 데이터를 주고받는 과정을 분석해 보면

ACK는 다음 기대되는 SEQ NUM이라는 사실도 알 수 있었습니다.

위의 빨간 네모칸을 분석해보면

클라이언트 쪽에서 보낸 SEQ num = 1이고, 데이터의 크기가 17 Byte이기 때문에 SEQ 17번까지 전송된 상태입니다.

그러므로 서버에서는 기대하는 다음 SEQ num이 18이겠습니다.

그래서 ACK가 18로 전송되었다는 것을 확인할 수 있었습니다.

---