[네트워크] 4계층 - TCP 프로토콜 (전송 과정 설명)

본 포스팅은 네트워크 스터디를 기반으로 개인 정리를 위한 포스팅입니다.
잘못된 부분이 있다면 언제든 지적해주시면 감사하겠습니다!

 

이번 정리에서는 서버가 클라이언트에게 데이터를 전송하는 과정을 TCP 프로토콜을 사용하여 설명함.

 

---

예를들어 서버의 HDD에 저장되어 있는 파일을 클라이언트에게 전송하기 위해서는 File System의 Driver를 통해 해당 파일을 서버 프로세스의 메모리에 올려야 함.

 

 

만약 대용량의 데이터를 전송하게 될 때 서버 프로세스의 메모리가 부족한 경우 해당 데이터를 분해해서 메모리에 적재하게 됨. (1.4MB → 64KB씩 분해)

 

서버 프로세스 메모리에 올려진 데이터의 일부는 Socket을 통해 클라이언트로 전송을 하기위해 TCP단에 있는 또다른 Buffer(메모리)로 카피가 발생

 

 

TCP → IP로 내려갈 때 또한 Buffer에 있는 데이터의 분해가 발생하는데 분해된 데이터를 Segment 패킷이라 부름.

 

하나하나의 Segment패킷은 재차 L2단(2계층)으로 내려오면서 Frame이라는 패킷으로 다시 캡슐화가 이루어지고 이러한 Frame패킷들이 클라이언트로 보내지게 됨.

 

---

Client

이제 Client가 Frame 패킷을 받았다는 가정하에 상황들을 알아보자.

 

클라이언트 단에서는 받은 Frame을 역캡슐화를 통해 [패킷 → Segment]로 데이터의 일부분을 꺼내 TCP Buffer에 적재함.

 

TCP Buffer에 적재한 순간 클라이언트는 서버에게 데이터를 잘 받았다고 알리는 ACK 신호를 전송.

 

여기서 중요한 점은 Server는 Frame을 계속해서 보내는 것이 아닌 일부분을 보낸 후 클라이언트에게 ACK신호를 받을 때 까지 Wait을 하기 때문에 UDP에 비해 속도지연이 발생함. >> TCP 흐름제어(Stop & Wait)

 

또한 클라이언트의 TCP Buffer의 크기가 가득차게 될 경우가 발생하는데

이렇게 될 경우 서버는 데이터를 보내지 않음. >> Wait 발생. 

 

이러한 상황을 해결하기 위해서 중요한 점은 TCP Buffer(Window size)가 부족한 상황이 오지않도록 Socket단에 있는 File I/O Buffer로 계속해서 Read를 해서 비워주어야함.

즉, Read 속도가 Network 수신속도 보다 빨라야 TCP Buffer가 부족하게 될 경우가 없어짐.

File I/O Buffer Read >> Network 수신속도

 

---

Question

서버측에서 클라이언트의 Window Size를 알 수 있는 방법 ?

>> TCP Protocol의 구조를 보면 Window라는 필드가 존재하고 해당 필드가 나타내는 의미는 현재 TCP Buffer의 남은 Size를 알려주는 것이기 때문에 패킷을 뜯어보면 알 수 있음.

 

TCP 프로토콜은 UDP 프로토콜을 사용한 통신에 비해 왜 안정적, 순서대로, 에러없이 데이터를 교환할 수 있는가?

>>

안정적 ? >> 신뢰성과 직결되고 그 이유는 TCP의 경우 ACK 응답절차 및 유실되거나 잘못된 패킷에 대한 재전송 처리과정이 존재하기 때문에 속도는 느리지만 신뢰적 및 안정적.

에러없이 ? >> TCP 프로토콜의 헤더를 살펴보면 Checksum이라는 필드가 있는데 해당 필드의 연산된 값을 통해 오류가 있는지 없는지 체크.

순서대로 ? >> 이 또한 프로토콜 구조의 헤더 중 Sequence Number에 의해 패킷 순서를 알 수 있고 이를 통해 순서에 대해 보장할 수 있음.

---

Reference

이해하면 인생이 바뀌는 TCP 송/수신 원리 (youtube.com)