Network - 네트워크의 원리(6)

connect 이후 write의 동작

이 동작의 중요한 점

1. 프로토콜 스택은 받은 데이터의 내용이 무엇이 쓰여있는지 알지 못합니다.
2. write를 호출할 때 송신 데이터의 길이를 지정하지만, 프로토콜 스택은 해당 길이만큼만 바이너리 데이터가 1바이트씩 차례로 나열되어 있다고 인식할 뿐입니다.

• 프로토콜 스택은 데이터를 어느 정도 송신 버퍼에 저장합니다.
• 바로바로 보내지 않는 이유는 작은 패킷을 많이 보내게 되면 효율이 저하되고 각각의 애플리케이션의 종류나 만드는 방법에 따라 결정되기 때문입니다.

버퍼에 얼마나 쌓을지 판단하나는 요소

1. MTU(Maximum Transmission Unit) : 패킷 한 개로 운반할 수 있는 디지털 데이터의 최대 길이, 이더넷에서는 보통 1,500바이트
2. MSS(Maximum Segment Size) : 헤더를 제외하고 한 개의 패킷으로 운반할 수 있는 TCP의 데이터의 최대 길이
   
3. 타이밍, 애플리케이션의 송신 속도가 느려지는 경우 MSS에 가깝게 데이터를 저장하면 시간이 걸려 송신 동작이 지연되므로 버퍼에 데이터가 모이지 않아도 적당한 곳에서 송신 동작을 실행해야 합니다. 따라서 프로토콜 스택은 내부에 타이머가 있어서 이것으로 일정 시간 이상 경과하면 패킷을 송신합니다.

데이터가 클 때는 분할하여 보냅니다.

• 송신 버퍼에 저장된 길이가 MSS나 MTU를 초과하게 되면 MSS나 MTU길이에 맞게 분할하여 패킷을 보내게 됩니다.
  
• MSS의 경우 데이터 조각의 모습을 가늠하여 데이터 조각을 송신하면 맨 앞부분에 TCP 헤더를 부가합니다. 그리고 나서 필요한 정보들을 모아서 IP 담당 부분에 건네주어 송신 동작을 실행합니다.

ACK

• 시퀀스 번호 : 데이터 조각을 송신할 때 TCP 헤더에 기록한 값
  
• 위의 그림과 같이 ACK 번호를 되돌려주는 동작을 수신 확인 응답이라고 부르며, 송신측은 이것을 통해 상대가 어디까지 수신했는지, 수신측에서 패킷이 누락되었는지 확인할 수 있습니다.
• 초기에 시퀀스 번호는 보안을 위해 난수 값으로 설정되어 있고, 난수 값이기 때문에 데이터의 송수신을 시작하기 전에 초기 값을 상대에게 알리게 되어 있습니다.
• SYN에 1을 설정할 때 시퀀스 번호에도 값을 설정하게 되어 있어 시퀀스 번호의 값이 초기값을 나타냅니다.
  
• 위와 같은 그림의 구조로 데이터의 송수신이 이루어지게 됩니다.
• 수신측에 패킷이 올바르게 도착한 것을 확인하고, 도착하지 않으면 다시 보내므로 네트워크의 오류가 발생했더라도 그것을 전부 검출하여 패킷을 다시 보내는 처리를 할 수 있습니다.
• 도중에 케이블이 분리되거나 서버가 다운되는 등의 이유로 TCP가 아무리 다시 보내도 데이터가 도착하지 않는 경우에는 한 없이 다시 보내면 곤란하므로 TCP는 몇 번 다시 보낸 후 회복의 전망이 없는 것으로 보고 강제로 종료하고 애플리케이션에 오류를 통지합니다.

정리

• 시퀀스 번호와 ACK 번호로 패킷이 수신측에 도착한 것을 확인할 수 있습니다.
• MSS, MTU, 타이머를 통해 버퍼에 얼마나 쌓을지 판단할 수 있습니다.

패킷 평균 왕복 시간으로 ACK 번호의 대기 시간을 조정합니다.

• 타임 아웃 : ACK 번호가 돌아오는 것을 기다리는 시간
• 네트워크가 혼잡하여 정체가 일어나면 ACK 번호가 돌아오는 것이 지연되기 때문에 타임 아웃 값을 적당한 값으로 설정해야 합니다.
• 그래서 TCP는 대기 시간을 동적으로 변경하는 방법을 사용하고 있습니다.
• 그 방법은 AcK가 돌아오는 시간을 계측해두고 ACK가 지연되면 대기 시간도 늘리고 빨리 오면 대기 시간을 짧게 설정합니다.

핑퐁 방식과 윈도우 제어 방식

• (a)의 핑퐁 방식은 한 개의 패킷을 보내고 ACK를 기다린다는 방법은 단순하고 이해하기 쉽지만, ACK가 돌아올 때까지의 시간 동안 아무 일도 하지 않고 기다리는 것은 비효율적입니다.
• 이러한 낭비를 줄이기 위해 TCP는 위의 그림의 (b)와 같은 윈도우 제어 방식을 사용하는데, 이 방법은 한 개의 패킷을 보낸 후 ACK를 기다리지 않고 연속해서 복수의 패킷을 보내는 방법입니다.
• 이렇게 되면 ACK 번호가 돌아올 때까지의 시간이 낭비되지 않습니다.
• 문제가 되는 것은 수신측의 버퍼를 초과할 때까지 패킷을 보내는 사태가 생길 수 있다는 것입니다. 버퍼를 초과한 데이터들은 없어져 버리므로 패킷이 도착해도 오류가 발생한 것처럼 처리하게 됩니다.
• 위의 문제점을 해결하기 위해 먼저 수신측에서 송신측에 수신 가능한 데이터 양을 통지하고, 수신측은 이 양(윈도우)을 초과하지 않도록 송신 동작을 실행합니다.
• 이 것이 핑퐁 방식과 다르게 연속해서 보낼 수 있는 윈도우 제어 방식입니다.
  
• 위의 그림과 같이 수신측은 수신 버퍼에 데이터를 임시 보관하고 수신 처리를 진행합니다. 그리고 수신 처리가 끝나고 수신 버퍼에 빈 부분이 생기면 그 분량만큼 수신할 수 있는 데이터 양을 늘리므로 TCP 헤더의 윈도우 필드에서 이를 송신측에 알립니다.
• 이렇게 해서 수신측의 버퍼를 초과하여 데이터를 보내는 일이 없어집니다.
• 윈도우 사이즈 : 수신 가능한 데이터 양의 최댓값
• 윈도우와 ACK를 같이 통지하게 되면 복수의 AcK 번호 통지가 연속해서 일어난 경우에도 패킷의 수를 줄일 수 있습니다.

write 다음에 read

• read를 경유해 프로토콜 스택에 제어가 넘어가게 되고, 프로토콜 스택이 움직이기 시작합니다.
• 프로토콜 스택은 수신 버퍼에서 수신 데이터를 추출하여 애플리케이션에게 건네줍니다. 이 때 응답 메시지가 돌아올 때까지 시간이 걸려 수신 버퍼에 데이터가 들어가지 않아 더 이상 작업을 먼저 진행할 수 없습니다.
• 그래서 프로토콜 스택은 애플리케이션에게 데이터를 추출하여 건네주는 작업을 잠시 보류합니다.
• 서버에서 응답 메시지의 패킷이 도착했을 때 데이터를 수신하여 애플리케이션에게 건네주는 작업을 재개합니다.

정리

• 수신한 데이터 조각과 TCP 헤더의 내용을 조사해 내용이 누락되었는지 검사하고, 문제가 없으면 ACK를 반송합니다.
• 데이터 조각을 수신 버퍼에 임시 보관하고, 조각을 연결해 애플리케이셚이 지정한 영역에 옮겨 기록한 후 애플리케이션에게 제어를 넘겨줍니다.
• 애플리케이션에 데이터를 건네주고 나서 타이밍을 가늠하여 윈도우를 송신측에 통지합니다.