데이터를 송·수신한다. - [Ch 02. TCP/IP의 데이터를 전기 신호로 만들어 보낸다.]

  이전 글을 통해 서버에 접속하는 방법을 알아보았다.

  이번에는 서버에 접속을 완료하고 connect에서 애플리케이션에 제어가 되돌아온 후의 데이터 송·수신 동작을 알아보도록 하자.

 

📙 1. 프로토콜 스택에 HTTP 리퀘스트 메시지를 넘긴다

  첫 번째 동작은 애플리케이션이 write를 호출하여 송신 데이터를 프로토콜 스택에 건네주는 것이다.

  프로토콜 스택은 데이터를 곧바로 송신하는 것이 아니라 일단 자체의 내부에 있는 송신용 버퍼 메모리 영역에 저장하고, 애플리케이션이 다음 데이터를 건네주기를 기다린다.

  만약 받은 데이터를 곧바로 보낸다면 작은 패킷을 많이 보낼 수 있다. 하지만, 이렇게 한다면 네트워크의 이용 효율이 저하되므로 어느 정도 데이터를 저장하고 나서 송·수신 동작을 한다.

 

  그렇다면 어느 정도 저장을 한다는 기준은 어떻게 정할까? 다음의 2가지 요소를 바탕으로 판단한다.

📌 1. MTU & MSS

  첫 번째 판단 요소는 한 패킷에 저장할 수 있는 데이터의 크기다.

  패킷 한 개로 운반할 수 있는 디지털 데이터의 최대 길이를 MTU(Maximum Transmission Unit)이라고 한다.

  그러나 패킷의 맨 앞부분에는 헤더가 포함되어 있으므로 헤더를 제외한 하나의 패킷으로 운반할 수 있는 데이터의 최대 길이는 MSS(Maximum Segment Size)다.

  그래서 애플리케이션으로부터 받은 데이터와 MSS를 고려하여 송신 동작을 결정한다.

📌 2. 타이밍

  두 번째 판단 요소는 타이밍이다.

  애플리케이션의 송신 속도가 느려지는 경우, MSS에 가깝게 데이터를 저장하면 저장하는데 시간이 많이 걸려 송신 동작이 지연된다.

  이런 경우 버퍼에 데이터가 모이지 않아도 적당한 곳에서 송신 동작을 수행하는 것이 낫다. 그래서 프로토콜 스택은 내부에 타이머가 있어서 이것으로 일정 시간 이상 경과하면 패킷을 송신한다.

 

  송신 동작을 판단하는 2가지 요소, '한 패킷에 저장할 수 있는 데이터의 크기'와 '타이밍'을 알아보았다.

  전자를 중시하면 패킷 길이가 길어져서 네트워크의 이용 효율이 높아지지만 버퍼에 머무는 시간만큼 송신 동작이 지연된다. 반대로 후자를 중시하면 지연은 적어지지만 이용 효율이 떨어지게 된다.

  그래서 양자를 절충해서 송신 동작을 실행해야 한다. (절충하는 방법은 OS 종류나 버전에 달라진다.)

 

  그리고 '바로 송신을 원할 경우', 데이터 송신을 의뢰할 때 옵션으로 '버퍼에 머무르지 않고 바로 송신할 것'이라고 지정할 수도 있다. 그러면 프로토콜 스택은 데이터를 버퍼에 머무르게 하지 않고 바로 송신 동작을 수행하게 된다.

 

 

📙 2. 데이터가 클 때는 분할하여 보낸다

  만약 데이터가 MSS의 길이를 초과하면 어떻게 될까? (블로그나 게시판 등의 긴 문장이 예시가 될 수 있다.)

  이 경우에는 데이터를 MSS의 크기에 맞게 분할하고, 분할한 조각을 한 개씩 패킷에 넣어 송신한다.

 

 

📙 3. ACK 번호를 사용하여 패킷이 도착했는지 확인한다

  위의 과정들을 통하여 데이터를 입력한 패킷이 서버를 향해 송신된다. 그러나 이것으로 송신 동작이 끝난 것은 아니다.

  송신한 패킷이 상대에게 올바르게 도착했는지 확인하고, 도착하지 않았다면 다시 송신을 하는 확인 동작까지 수행을 해야 한다.

 

  수신 여부를 확인할 때는 '시퀀스 번호', '데이터의 크기', 'ACK 번호'를 이용한다.

• 데이터를 조각으로 분할할 때 조각이 통신 시작부터 몇 번째 바이트에 해당하는지 시퀀스 번호에 저장한다.
• 패킷 전체의 길이에서 헤더 길이를 빼서 데이터의 크기를 저장한다.
• 수신 측은 시퀀스 번호와 데이터의 크기를 이용해서 몇 번째 바이트까지 수신한 것인지 계산하여 ACK 번호를 저장한다.

  그래서 위의 그림과 같이 '시퀀스 번호', '데이터의 크기', 'ACK 번호'를 이용하여 송신 측은 상대가 어디까지 데이터를 수신했는지 파악한다.

 

  그림에서는 시퀀스 번호를 1로 시작하였다.

  하지만, 실제에서는 시퀀스 번호가 1부터 시작하지 않고 난수를 바탕으로 산출한 초기값으로 시작한다. 시퀀스 번호를 항상 1부터 시작하면 이것을 예측하여 악의적인 공격을 할 가능성이 있기 때문이다.

  그래서 서버와 접속을 할 때 시퀀스 번호의 초기값을 설정한다.

 

실제 움직임은 다음과 같다.

1. 접속 동작을 실행할 때 클라이언트에서 서버로 보내는 데이터에 관한 시퀀스 번호의 초기값을 클라이언트에서 산출하여 서버에 통지한다.
2. ACK 번호와 서버에서 클라이언트에 보내는 데이터에 관한 시퀀스 번호의 초기값을 클라이언트에게 보낸다.
3. 클라이언트는 서버에게 ACK 번호를 전송한다.
4. 시퀀스 번호와 데이터를 전송한다.
5. 해당 데이터에 대한 ACK 번호를 송신한다.

 

  TCP는 이 방법으로 상대가 데이터를 잘 받았는지 확인한다.

  확인할 때까지 송신한 패킷을 송신용 버퍼 메모리 영역에 보관한다. 그리고 송신한 데이터에 대응하는 ACK 번호가 상대로부터 돌아오지 않으면 패킷을 다시 보낸다.

  이 방법을 이용하면 네트워크의 어느 부분에서든 오류가 발생했더라도 그것을 전부 검출하여 회복 처리(패킷을 다시 보내는 것)를 취할 수 있다. 그래서 다른 곳에서 오류를 회복 조치할 필요가 없게 된다.

 

 

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

  ACK 번호가 돌아오는 것을 기다리는 시간을 타임아웃 값이라고 한다.

 

  네트워크가 혼잡하면 대기 시간을 어느 정도 길게 설정해서 패킷을 다시 보내지 않도록 해야 한다. (다시 보내기는 단순한 낭비일 뿐만 아니라 네트워크를 더욱 혼잡시킨다.)

  그렇다고 대기 시간을 너무 길게 하면 패킷을 다시 보내는 동작이 지연되어 속도 저하의 원인이 된다.

 

  그래서 대기 시간을 너무 짧지도, 길지도 않은 적절한 값으로 설정해야 한다.

  대기 시간에 영향을 주는 요인(서버와의 거리, 정체 시의 지연,...) 이 너무 많기 때문에 대기 시간을 일정한 값으로 설정하는 방법은 적절하지 않다.

 

  그래서 TCP는 대기 시간을 동적으로 변경하는 방법을 취한다.

  그래서 ACK 번호가 돌아오는 시간을 기준으로 대기 시간을 판단하게 된다. ACK 번호가 돌아오는 시간이 지연되면 대기 시간을 늘리고, ACK 번호가 돌아오는 시간이 빠르다면 대기 시간을 짧게 설정한다.

 

 

📙 5. 윈도우 제어 방식으로 효율적으로 ACK 번호를 관리한다

  '한 개의 패킷을 보내고 ACK 번호가 돌아올 때까지 기다린다'라는 것을 전제로 송신 동작을 살펴보았다.

  하지만, ACK 번호가 돌아올 때까지의 시간 동안 아무 일도 하지 않고 기다리는 것은 시간 낭비다. 이러한 낭비를 줄이기 위해 TCP는 윈도우 제어라는 방식을 사용한다.

 

  윈도우 제어는 한 개의 패킷을 보낸 후 ACK 번호를 기다리지 않고 차례대로 연속해서 복수의 패킷을 보내는 방법이다.

  여기서 주의할 점은 ACK 번호를 기다리지 않고 차례로 패킷을 보내게 된다면 수신 측의 능력을 초과하여 패킷을 보내는 사태가 발생할 수 있다는 것이다.

 

  윈도우 제어 방식은 아래의 방식을 이용하여 문제를 해결하였다.

1. 수신 측에서 송신 측에 수신 가능한 데이터의 양을 통지한다.
2. 수신 측은 이 양을 초과하지 않도록 송신 동작을 수행한다.

 

  수신 측은 수신 처리가 끝나고 수신 버퍼에 빈 부분이 생기면 그 분량을 TCP 헤더의 윈도우 필드에 기록하여 송신 측에 알린다. 송신 측은 윈도우 필드에 기록된 값을 보고 송신을 결정한다.

  또한, 수신 가능한 데이터 양의 최댓값을 윈도우 사이즈라고 부르며, TCP를 정밀 조정하는 매개변수의 하나로 알려져 있다.

 

 

📙 6. ACK 번호와 윈도우를 합승한다

  송·수신 동작을 위해 'ACK 번호'와 '윈도우를 통지하는 타이밍'을 고려해야 한다는 것을 살펴보았다.

  그러면 두 개를 언제 보내는 게 맞을까?

  'ACK 번호'와 '윈도우 통지의 동작'이 언제 각각 일어나는지 살펴보고 두 개의 조합을 통해 적절한 타이밍을 살펴보자.

 

📌  1. ACK 번호를 전송해야 하는 경우

  ACK 번호는 수신 측에서 데이터를 받았을 때 내용을 조사하여 정상 수신을 확인할 수 있는 경우에만 송신 측에 보낸다. 즉, 데이터를 수신한 후 즉시 보낸다고 생각하면 된다.

📌 2. 윈도우 통지의 동작이 일어나는 경우

  윈도우 통지가 필요한 것은 수신 측이 수신 버퍼에서 데이터를 추출하여 애플리케이션에 건네주었을 때다. 이 동작은 수신 측의 애플리케이션에서 보낸 의뢰가 계기가 되어 일어나므로 송신 측에서는 이 동작이 언제 일어날지 알 수 없다.

  즉, 수신 측에서 애플리케이션에 데이터를 건네주고 수신 버퍼의 빈 영역이 늘어났을 때가 윈도우 통지의 타이밍이다.

🧬 3. 조합 1 - 따로 보내기

  본래의 개념을 그대로 실현하면 데이터의 패킷을 수신할 때마다 ACK 번호 통지와 윈도우 통지의 패킷이 하나씩 따로 송신 측에 보내진다.

  그러나, 이렇게 해서는 수신 측에서 송신 측에 보내는 패킷이 많아져서 효율성이 저하된다.

🧬 4. 조합 2 - 'ACK 번호 + 윈도우 통지'를 가진 하나의 패킷으로 보내기

  ACK 번호나 윈도우를 통지할 때 소켓에 바로 보내지 않고 잠시 기다릴 수도 있다.

  이렇게 기다리는 사이에 다음 통지 동작이 일어나면 양쪽을 상승시켜서 한 개의 패킷으로 묶어서 보내게 된다.

  예를 들어 ACK 번호의 송신을 대조할 때 윈도우 통지가 일어나면 ACK 번호와 윈도우를 한 개의 패킷에 합승시켜서 통지한다.

🧬 5. 조합 3 - 연속된 것을 하나로 처리하기

  ACK 번호는 데이터를 어디까지 받았는지, 즉 수신한 데이터의 끝이 어디인지를 송신 측에 알리는 것이므로 ACK 번호 통지가 연속하여 일어나면 최후의 것만 통지하고 도중의 것은 생략해도 된다.

  이렇게 하면 패킷을 줄일 수 있고, 윈도우 통지가 연속된 경우도 마찬가지로 패킷을 줄일 수 있다.

 

 

📙 7. HTTP 응답 메시지를 수신한다

  이전까지는 브라우저의 의뢰를 받아 프로토콜 스택이 HTTP 리퀘스트 메시지를 보내는 일련의 동작을 살펴보았다.

  이후에 브라우저는 서버에서 돌아오는 응답 메시지를 받기 위해 read 프로그램을 호출한다. 데이터를 수신할 때도 데이터를 송신할 때와 마찬가지로 데이터를 일시 보관하는 수신 버퍼를 사용한다.

 

  리퀘스트 메시지의 송신을 완료하고 응답 메시지가 돌아왔다면, 프로토콜 스택은 수신 버퍼에서 수신 데이터를 추출하여 애플리케이션에게 건네준다.

  만약 리퀘스트 메시지의 송신을 완료하고 응답 메시지가 아직 돌아오지 않았다면, 프로토콜 스택은 잠시 대기를 하였다가 서버에서 응답 메시지의 패킷이 도착했을 때 그것을 수신하여 애플리케이션에게 건네준다.

 

해당 글은 Tsutomu Tone 님의 '성공과 실패를 결정하는 1%의 네트워크 원리'를 참고하였습니다.