성공과 실패를 결정하는 1%의 네트워크 원리 2장: 프로토콜 스택, LAN 어댑터

Chapter 2. TCP/IP의 데이터를 전기 신호로 만들어 보낸다.

이번장에서는 OS에 내장된 네트워크 제어용 소프트웨어(프로토콜 스택)와 네트워크용 하드웨어(LAN 어댑터)가 브라우저에서 받은 메시지를 서버에 송출하는 동작을 탐험한다.

01. 소켓을 작성한다.

1. 프로토콜 스택의 내부 구성

• 애플리케이션의 아랫부분에는 Socket 라이브러리가 있으며, 그 안에는 리졸버가 내장되어 있다. 리졸버가 DNS 서버에 조회하는 동작을 실행한다.
• OS의 내부에는 프로토콜 스택이 있다.
• 프로토콜의 스택 윗부분에는 TCP라는 프로토콜을 사용하여 데이터 송,수신을 담당하는 부분과 UDP라는 프로토콜을 사용하여 데이터 송,수신을 담당하는 부분이 있다. 이 둘이 애플리케이션에서 보낸 의뢰를 받아 송,수신 동작을 실행한다.
• 브라우저나 메일 등의 일반적인 애플리케이션이 데이터를 송,수신할 경우에는 TCP를 사용한다.
• DNS 서버에 대환 조회 등에서 짧은 제어용 데이터를 송,수신할 경우에는 UDP를 사용한다.
• 그 아래에는 IP 프로토콜을 사용하여 패킷 송,수신 동작을 제어하는 부분이 있다.
• 인터넷에서 데이터를 운반할 때는 데이터를 작게 나누어 패킷이라는 형태로 운반한다.
• IP에는 ICMP와 ARP라는 프로토콜을 다루는 부분이 있다.
• ICMP는 패킷을 운반할 때 발생하는 오류를 통지하거나 제어용 메시지를 통지할 때,
• ARP는 IP 주소에 대응하는 이더넷의 MAC 주소를 조사할 때 사용한다.
• IP의 아래에 있는 LAN 드라이버는 LAN 어댑터의 하드웨어를 제어한다.

2. 소켓의 실체는 통신 제어용 제어 정보

• 프로토콜 스택은 내부에 제어 정보를 기록하는 메모리 영역을 가지고 있으며, 여기에 통신 동작을 제어하기 위한 제어 정보를 기록한다.
• 제어 정보가 소켓의 실체이며, 제어 정보를 기록한 메모리 영역이 소켓의 실체라고 생각해도 좋다.
• 대표적인 제어 정보는 통신 상대의 IP와 포트번호, 통신 동작이 어떤 진행 상태에 있는가 하는 것이다.
• 프로토콜 스택은 이 제어 정보를 참조하면서 동작한다.
• 소켓에는 응답이 돌아오는지의 여부와 송신 동작 후의 경과 시간 등이 기록되어 있다.
• 프로토콜 스택은 이 정보를 보고 포기하거나 다시 보내는 동작을 실행한다.

3. Socket의 호출했을 때의 동작

• 애플리케이션이 socket을 호출하여 소켓을 만들 것을 의뢰하면 프로토콜 스택은 의뢰에 따라 한 개의 소켓을 만든다.
• 이때 프로토콜 스택이 최초로 하는 일은 소켓 한 개 분량의 메모리 영역을 확보하는 것이다.
• 이 시점에서 소켓은 작성된 직후라서 아직 송,수신 동작이 시작되지 않은 초기 상태이므로 초기 상태임을 나타내는 제어 정보를 소켓의 메모리 영역에 기록하는데, 이 과정을 통해 소켓이 만들어진다.
• 소켓이 만들어지면 소켓을 나타내는 디스크립터를 애플리케이션에 알려준다.
• 디스크립터는 프로토콜 스택의 내부에 있는 다수의 소켓 중 어느 것을 가리키는지를 나타내는 번호표와 같은 정보다.
• 디스크립터를 받은 애플리케이션은 이후 프로토콜 스택에 데이터 송,수신 동작을 의뢰할 때 디스크립터를 통지한다.

02. 서버에 접속한다.

1. 접속의 의미

• 접속 동작의 첫 번째 동작은 통신 상대와의 사이에 제어 정보를 주고받아 소켓에 필요한 정보를 기록하고 데이터 송,수신이 가능한 상태로 만드는 것이다.
• 클라이언트 측의 IP 주소나 포트 번호를 서버측에 알리는 것이 제어 정보 주고받기의 구체적인 예시다.
• 접속 동작에서 주고받는 제어 정보는 통신의 규칙으로 정해져 있으므로 규칙에 따라 접속 동작을 실행하면 필요한 정보가 전달되고 데이터를 송,수신할 수 있는 상태가 된다.
• 데이터 송, 수신 동작을 실행할 때는 송,수신하는 데이터를 일시적으로 저장하는 메모리 영역이 필요한데, 이 메모리 영역을 버퍼 메모리라고 부른다.
• 버퍼 메모리의 확보도 접속 동작을 할 때 실행되는데, 이것이 '접속'한다는 동작의 의미다.

2. 맨 앞부분에 제어 정보를 기록한 헤더를 배치한다.

• '제어 정보'에는 크게 나누어 두 종류가 있다.
• 하나는 클라이언트와 서버가 서로 연락을 절충하기 위해 주고 받는 제어 정보다.
  이것은 접속 동작뿐만 아니라 데이터를 송,수신하는 동작이나 연결을 끊는 동작도 포함하여 통신 동작 전체에서 어떤 정보가 필요한지 검토하여 내용을 TCP 프로토콜의 사양으로 규정하고 있다.
• 이런 제어 정보는 다양한 항목으로 규정되어 있다. 또한 항목들이 고정화되어 있으므로 접속, 송신, 수신, 연결 끊기의 각 단계에서 클라이언트와 서버가 대화할 때마다 거기에 이 제어 정보를 부가한다.
• 클라이언트와 서버 사이에 주고 받는 패킷의 맨 앞부분에 부가한다.
• 이 제어 정보를 패킷의 맨 앞부분에 배치하는 곳부터 헤더라고 부른다.
• 클라이언트와 서버는 이 헤더에 필요한 정보를 기록하여 연락을 취하면서 통신 동작을 진행한다.
• 즉 송신 동작 개시, 데이터를 수신, 데이터를 송신 등의 통신 동작을 헤더의 정보를 바탕으로 진행한다.
• 제어 정보는 소켓에 기록하여 프로토콜 스택의 동작을 제어하기 위한 정보가 더 있다.
• 여기에서는 애플리케이션에서 통지된 정보, 통신 상대로부터 받은 정보 등이 수시로 기록된다.
• 소켓의 제어 정보는 프로토콜 스택의 프로그램과 일체화 되어 있다.

3. 접속 동작의 실체

• 접속 동작은 애플리케이션이 Socket 라이브러리 connect를 호출하는 곳부터 시작한다.
• connect(<디스크립터>, <서버측의 IP 주소와 포트 번호>, ...)
• 여기에 서버측의 IP 주소와 포트 번호를 쓰면 명령이 프로토콜 스택의 TCP 담당 부분에 전달된다.
• 그러면 TCP 담당 부분은 IP 주소로 표시된 상대, 즉 서버의 TCP 담당 부분과의 사이에 제어 정보를 주고 받는다.
• 먼저 데이터 송, 수신 동작의 개시를 나타내는 제어 정보를 기록한 헤더를 받는다.
• TCP 헤더에는 다수의 항목이 있는데, 지금 중요한 것은 송신처와 수신처의 포트 번호다.
• 이를 통해 송신처가 되는 클라이언트측의 소켓과 수신처가 되는 서버측의 소켓을 지정할 수 있다.
• 즉 접속해야 하는 소켓이 어느 것인지 확실히 하고 컨트롤 비트인 SYN이라는 비트를 1로 만든다.
• TCP 헤더를 만들면 이것을 IP 담당 부분에 건네주어 송신하도록 의뢰한다.
• 그러면 IP 담당 부분이 패킷 송신 동작을 실행하고 네트워크를 통해 패킷이 서버에 도착하면 서버측의 IP 담당 부분이 이것을 받아 TCP 담당 부분에 건넨다.
• 이후 서버측의 TCP 담당 부분이 TCP 헤더를 조사하여 기록되어 있는 수신처 포트 번호에 해당하는 소켓을 찾아내 필요한 정보를 기록하고 접속 동작이 진행중이라는 상태가 된다.
• 이 과정이 끝나면 서버의 TCP 담당 부분은 응답을 돌려보낸다.
• 클라이언트와 마찬가지로 송신처와 포트 번호나 SYN 비트 등을 설정한 TCP 헤더를 만든다. 그리고 응답을 돌려보낼 때 ACK라는 컨트롤 비트도 1로 만든다.
• 이것은 패킷을 받은 것을 알리기 위한 동작이다.
• 이제 TCP 헤더를 IP 담당 부분에 건네주어 클라이언트에 반송하도록 의뢰한다.
• 클라이언트가 TCP 헤더를 조사하는데 SYN이 1이면 접속 성공이므로 소켓에 서버의 IP 주소나포트 번호 등과 함께 소켓에 접속 완료를 나타내는 제어 정보를 기록한다.
• 그리고 서버가 응답을 돌려보낼 때 ACK 비트를 1로 만들었는데, 이것과 같이 패킷이 도착한 것을 서버에 알리기 위해 ACK 비트를 1로 만든 TCP 헤더를 반송한다. 이것이 서버에 도착하면 접속 동작의 대화가 끝난다.
• 이때 파이프와 같은 것으로 소켓이 연결되었다고 생각할 수 있다. 이 파이프와 같은 것을 커넥션이라고 한다.
• 이렇게 커넥션이 이루어지면 프로토콜 스택의 접속 동작이 끝나므로 connect의 실행이 끝나면서 애플리케이션을 제어할 수 있게 된다.

03. 데이터를 송,수신 한다.

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

• connect에서 애플리케이션에 제어가 되돌아오면 데이터를 송,수신 동작에 들어가는데,
  애플리케이션이 write를 호출하여 송신 데이터를 프로토콜 스택에 건네주는 곳부터 시작된다.
• 프로토콜 스택은 받은 데이터의 내용에 무엇이 쓰여있는지 알지 못한다. write를 호출할 때 송신 데이터의 길이를 지정하지만,
  프로토콜 스택은 해당 길이만큼만 바이너리 데이터가 1바이트씩 차례로 나열되어 있다고 인식한다.
• 프로토콜 스택은 받은 데이터를 곧바로 송신하지 않고 자체의 내부에 있는 송신용 버퍼 메모리 영역에 저장하고,
  애플리케이션이 다음  데이터를 건네주기를 기다린다.
• 송신을 의뢰할 때는 애플리케이션에서 프로토콜 스택에 건네주는 데이터의 길이는 애플리케이션의 종류나 만드는 방법에 따라 결정된다.
• 이런 상황에서 받은 데이터를 곧바로 보내는 단순한 방법은 작은 패킷을 많이 보낼수도 있다는 뜻이다.
• 그러면 네트워크 이용 효율이 저하되므로 어느 정도 데이터를 저장하고 나서 송,수신 동작을 한다.
• 어느 정도까지 저장한 후 송신동작을 할 때는 OS의 종류나 버전에 따라 달라진다. 따라서 다음과 같은 요소를 바탕으로 판단한다.
• 첫 번째 판단 요소는 한 패킷에 저장할 수 있는 데이터의 크기다.
• 프로토콜 스택은 MTU라는 매개변수를 바탕으로 판단한다.
• MTU는 한 패킷으로 운반할 수 있는 디지털 데이터의 최대 길이로, 이터넷에서는 보통 1500 바이트가 된다.
• MTU에는 패킷의 맨 앞부분에 해더가 포함되어 있으므로 여기부터 헤더를 제외한 것이 하나의 패킷으로 운반할 수 있는 데이터의 최대 길이가 되고, 이것을 MSS라고 한다.
• 두 번째 판단 요소는 타이밍이다.
• 애플리케이션의 송신 속도가 느려지는 경우 MSS에 가깝게 데이터를 저장하면
  여기에서 시간이 걸려 송신 동작이 지연되므로 버퍼에 데이터가 모이지 않아도 적당한 곳에서 송신 동작을 실행해야 한다.
• 따라서 프로토콜 스택은 내부에 타이머가 있어서 이것으로 일정 시간 이상 경과하면 패킷을 송신한다.
• 데이터의 크기를 중시하면 네트워크의 이용 효율이 높아지지만 버퍼에 머무는 만큼 송신 동작이 지연될 수 있다.
• 타이밍을 중시하면 지연은 적어지지만 이용 효율이 떨어지므로 양자를 절충해서 적당히 시간을 가늠하여 송신 동작을 실행해야 한다.
• 애플리케이션에서도 송신의 타이밍을 제어할 수 있다.
• 브라우저와 같이 대화형 애플리케이션이 서버에 메시지를 보낼 때는 버퍼에 머무는만큼 응답 시간이 지연되므로 버퍼에 머무르지 않고 바로 송신하는 옵션을 사용하는 경우가 많을 것이다.

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

• 많은 데이터를 전송할 경우에는 송신 버퍼에 저장된 데이터는 MSS의 길이를 초과하므로 다음 데이터를 기다릴 필요가 없다.
• 따라서 송신 버퍼에 들어있는 데이터를 맨 앞부터 차례대로 MSS의 크기에 맞게 분할하고,
  분할한 조각을 한 개씩 패킷에 넣어 송신한다.
• 이렇게 해서 송신 버퍼에 저장한 데이터 조각의 모습을 가늠하여 데이터 조각을 송신하면 맨 앞부분에 TCP 헤더를 부가한다.
• 그리고 소켓에 기록되어 있는 제어 정보를 바탕으로 송신처 포트 번호나 수신처 포트 번호 등 필요한 항목을 기록하고, IP 담당 부분에 건네주어 송신 동작을 실행한다.

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

• TCP에는 송신한 패킷이 상대에게 올바르게 도착했는지 확인하고, 도착하지 않았으면 다시 송신하는 기능이 있으므로 패킷을 송신한 후에는 확인 동작으로 넘어간다.
• TCP 담당 부분은 데이터를 조각으로 분할할 때 조각이 통신 개시부터 따져서 몇 번째 바이트에 해당하는지를 세어 둔다.
• 그리고 데이터의 조각을 송신할 때 세어둔 값을 TCP 헤더에 기록하는데, 시퀀스 번호라는 항목이 이에 해당한다.
• 패킷 전체의 길이에서 헤더 길이를 빼면 데이터의 크기를 계산할 수 있으므로 수신측에서 이 방법을 사용해 크기를 산출한다.
• 예를 들어 1460번째 바이트까지 수신 완료한 상태에서 시퀀스 번호가 1461인 패킷이 도착하면 누락이 없다는 것을 알 수 있고, 시퀀스 번호가 1461인 패킷이 도착하지 않았는데 시퀀스 번호가 2921인 패킷이 도착하면 누락된 것을 알 수 있다.
• 이렇게 해서 누락이 없는 것을 확인하면 수신측은 그 이전에 수신한 데이터와 합쳐서 데이터를 몇 번째 바이트까지 수신한 것인지 계산하고, 그 값을 TCP 헤더의 ACK 번호에 기록하여 송신측에 알려준다.
• 이 ACK 번호를 되돌려주는 동작을 수신 확인 응답이라고 부르며, 송신측은 이것을 통해 상대가 어디까지 수신했는지를 파악하고 재송신할 수 있다.
• 실제로 시퀀스 번호가 1부터 시작하지 않고 난수를 바탕으로 산출한 초기 값으로 시작한다. 악의적인 공격을 막기 위해서다.
• 그러나 난수로 설정하면 몇 번이 초기 값인 지 알 수 없는데,
  사실 앞에서 SYN이라는 제어 비트를 1로하여 서버로 보냈는데, 그것이 초기 값을 통지하는 것이다.
• SYN에 1을 설정할 때 시퀀스 번호에도 값을 설정하게 되어 있어 시퀀스 번호의 값이 초기 값을 나타낸다.
• 정리하면 시퀀스 번호와 ACK 번호로 패킷이 수신측에 도착한 것을 확인한다.

실제 움직임

1. 접속 동작을 실행할 때 클라이언트에서 서버로 보내는 데이터에 관한 시퀀스 번호의 초기 값을 클라이언트에서 산출해 서버에 통지한다.
2. 그러면 서버에서 초기값으로부터 ACK 번호를 산출해 클라이언트에 반송한다. 이때 서버에서 클라이언트에 보내는 데이터에 관한 시퀀스 번호의 초기값을 서버에서 산출하여 이 값도 함께 클라이언트에 통지한다.
3. 그러면 클라이언트에서도 서버와 마찬가지로 받은 시퀀스 번호의 초기값으로부터 ACK 번호를 산출해 서버에 반송한다.
4. 이제 시퀀스 번호, ACK 번호가 준비되었으므로 데이터 송,수신 동작에 들어간다. 
   웹의 경우는 최초에 클라이언트에서 서버로 메시지를 보낼 것이고, 데이터와 함께 시퀀스 번호를 보낸다.
5. 그러면 데이터를 수신한 서버에서 ACK 번호를 반송한다.
6. 서버에서 클라이언트에 데이터를 보내는 경우는 그 반대다. 시퀀스 번호와 데이터를 클라이언트에게 보내며,
   클라이언트는 ACK 번호를 서버에게 반송한다.

TCP는 이 방법으로 상대가 받은 데이터를 받은 것을 확인한다. 확인할 때까지 송신한 패킷을 송신용 버퍼 메모리 영역에 보관한다.

그리고 송신한 데이터에 대응하는 ACK 번호가 상대로부터 돌아오지 않으면 패킷을 다시 보낸다.

 

수신측에 패킷을 올바르게 도착한 것을 확인하고,
도착하지 않으면 다시 보내므로 네트워크의 어디에서 오류가 발생했더라도 그것을 전부 검출해 회복처리를 할 수 있다.

이 구조로 인해 LAN 어댑터, 버퍼, 라우터 등 다른 곳에서 모두 회복 조치를 취하지 않는다.

TCP에 맡기면 오류가 발생해도 데이터가 문제 없이 상대에게 도착하므로 애플리케이션의 송신 동작은 송신한 채로 끝난다.

단 도중에 케이블이 분리되거나 서버가 다운되는 등의 이유로 TCP가 아무리 다시 보내도 데이터가 도착하지 않는 경우가 있다.

이때 계속 재전송하면 곤란하므로 TCP가 회복의 전망이 없는 것으로 판단하면 데이터 송신 동작을 강제 종료하고 애플리케이션에 오류를 통지한다.

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

• ACK 번호가 돌아오는 것을 기다리는 시간인데, 이 대기 시간을 타임아웃 값이라고 한다.
• 네트워크가 혼잡해 정체가 일어나면 ACK 번호가 돌아오는 것이 지연되므로 이것을 예측하여 대기 시간을 어느 정도 길게 설정해야 한다.
• 그러지 않으면 ACK 번호가 돌아오기 전에 다시 보내야 하는 사태가 발생한다.
• ACK 번호의 반송이 지연되도록 한 사태는 혼잡이 원인인 경우가 많으므로 거기에 헛된 패킷을 보내면 혼잡을 악화시킨다.
• 그렇다고 대기 시간이 너무 길면 패킷을 다시 보내는 동작이 지연되어 속도 저하의 원인이 된다.
• TCP는 대기 시간을 동적으로 변경하는 방법을 취하고 있다.
• ACK 번호가 돌아오는 시간을 기준으로 대기 시간을 판단한다.
• 데이터 송신 동작을 실행하고 있을 때 항상 ACK 번호가 돌아오는 시간을 계측해 둔다.
• ACK 번호가 돌아오는 시간이 지연되면 이것에 대응하여 대기 시간을 늘리고, ACK 번호가 곧바로 돌아오면 대기 시간을 짧게 설정한다.

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

• 앞에서 배운 것처럼 1개의 패킷을 보내고 ACK 번호를 기다리는 방법은 시간 낭비가 극심하다.
• 이런 낭비를 줄이기 위해 윈도우 제어라는 방식에 따라 송신과 ACK 번호 통지의 동작을 실행한다.
• 윈도우 제어는 한 개의 패킷을 보낸후 ACK 번호를 기다리지 않고 차례대로 연속해서 복수의 패킷을 보내는 방법이다.
  그러면 ACK 번호가 돌아올 때까지의 시간이 낭비되지 않는다.
• 이렇게 해서 ACK 번호를 기다리는 시간의 낭비가 없어지는데, 주의할점이 있다.
  바로 ACK 번호를 기다리지 않고 차례로 패킷을 보내면 수신측의 능력을 초과하여 패킷을 보내는 사태가 일어날 수도 있다.
• 수신측에서는 TCP 패킷을 수신하면 일단 수신용 버퍼 메모리에 일시 보관하며, 원래 데이터를 복원한 후 애플리케이션에 건넨다.
  그런데 애플리케이션에 건네주는 속도보다 빠른 속도로 데이터가 도착하면 수신 버퍼에 데이터가 쌓여서 넘쳐버린다.
• 넘친 데이터는 없어지므로 패킷이 도착해도 오류가 발생한 것처럼 되는데 이것이 수신측의 능력을 초과한다는 뜻이다.
• 이 문제를 해결하기 위해서는 수신측에서 송신측에 수신 가능한 데이터 양을 통지하고,
  수신측은 이 양을 초과하지 않도록 송신 동작을 실행해야 한다. 이것이 윈도우 제어 방식의 개념이다.
• 수신측은 수신 버퍼에 데이터를 임시 보관하고 수신 처리를 진행하는데, 수신처리가 끝나고 수신 버퍼에 빈 부분이 생기면 그 분량만큼 수신할 수 있는 데이터 양을 늘리므로 TCP 헤더의 윈도우 필드에서 이것을 송신측에 알린다.
  이렇게 해서 수신측의 능력을 초과해 데이터를 보내는 일이 없어진다.
• 수신 가능한 데이터 양의 최대값을 윈도우 사이즈라고 부르며, TCP를 정밀 조정하는 매개변수의 하나로 알려져 있다.

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

• 송,수신 동작의 효율성을 높이기 위해 ACK 번호와 윈도우를 통지하는 타이밍을 고려해야 한다.
• 윈도우의 값은 송신측이 데이터를 송신할때마다 송신한 데이터만큼 감산하여 스스로 산출할 수 있다.
• 윈도우 통지가 필요한 것은 수신측이 수신 버퍼에서 데이터를 추출하여 애플리케이션에 건네주었을 때다.
• 그러므로 수신측에서 애플리케이션에 데이터를 건네주고 수신 버퍼의 영역이 늘어났을 때 이것을 송신측에 통지해야 하는데,
  이것이 윈도우 통지의 타이밍이다.
• ACK 번호는 수신측에서 데이터를 받았을 때 내용을 조사하여 정상 수신을 확인할 수 있는 경우에만 송신측에 보낸다.
• 그렇다면 송신측에서 보낸 데이터가 수신측에 도착하여 수신 동작이 정상적으로 완료되었을 때 ACK 번호를 송신측에 통지하고 잠시 후 데이터를 애플리케이션에 건네주었을 때 윈도우를 통지하는 상태가 된다. 즉 본래의 개념은 ACK 번호 통지, 윈도우 통지 패킷이 하나씩 2번 송신측에 보내져야 한다.
• 그러나 이런 방식은 패킷이 많아져 효율성이 저하된다.
• 수신측은 ACK 번호나 윈도우를 통지할 때 소켓을 바로 보내지 않고 잠시 기다린다. 
• 이렇게 기다리는 사이에 다음 통지 동작이 일어나면 양쪽을 상승시켜서 한 개의 패킷으로 묶어 보낸다.
• 예를 들어 ACK 번호의 송신을 대조할 때 윈도우 통지가 일어나면 ACK 번호와 윈도우를 한 개의 패킷에 합승시켜서 통지하여 패킷의 수를 줄일 수 있다.
• 복수의 ACK 번호 통지가 연속해서 일어난 경우에도 패킷의 수를 줄일 수 있다.
• ACK 번호는 데이터를 어디까지 받았는지, 즉 수신한 데이터의 끝이 송신측에 알리는 것이므로 ACK 번호 통지가 연속하여 일어나면 최후의 것만 통지하고 도중의 것은 생략해도 좋다.윈도우 통지도 마찬가지로 도중 내용은 생략하고 최후의 것만 통지하면 된다.

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

• 브라우저는 리퀘스트 메시지를 송신해 달라고 의뢰하고, 이것이 끝나면 서버에서 돌아오는 응답 메시지를 받기 위해 read 프로그램을 호출한다.
• read를 경유해 프로토콜 스택에 제어가 넘어간다. 데이터를 수신할 때도 데이터를 일시 보관하는 수신 버퍼를 사용한다.
• 먼저 프로토콜 스택은 수신 버퍼에서 수신 데이터를 추출해 애플리케이션에 건네준다.
• 이때 리퀘스트 메시지의 송신을 완료하고 나서 얼마 안 된 시점이라면 아직 응답 메시지가 돌아오지 않는다.
• 그래서 프로토콜 스택은 의뢰받은 작업, 즉 수신 버퍼에서 수신 데이터를 추출하여 애플리케이션에 건네주는 작업ㅇ르 잠시 보류한다.
  서버에서 응답 패키지의 패킷이 도착했을 때 그것을 수신해 애플리케이션에 건네준다.
• 수신한 데이터 조각과 TCP 헤더의 내용을 조사해 도중에 데이터가 누락되었는지 검사하고, 문제가 없으면 ACK 번호를 반송한다.
• 그리고 데이터 조각을 수신 버퍼에 일시 보관하고, 조각을 연결해 데이터를 원래 모습으로 복원한 후 애플리케이션에 건네준다.
  즉 수신 데이터를 애플리케이션이 지정한 메모리 영역으로 옮겨 기록한 후 애플리케이션에 제어를 되돌려준다.
• 애플리케이션에 데이터를 건네주면 타이밍을 가늠하여 윈도우를 송신측에 통지한다.

04. 서버에서 연결을 끊어 소켓을 말소한다.

1. 데이터를 보내기를 완료했을 때 연결을 끊는다.

• 데이터 보내기를 완료한 쪽에서 연결 끊기에 들어가는데, 서버측에서 연결 끊기에 들어간다고 가정하자.
• 그러면 서버측의 애플리케이션이 먼저 Socket 라이브러리의 close를 호출한다.
• 그러면 서버측의 프로토콜 스택이 TCP 헤더를 만들고, 여기에 연결 끊기를 나타내는 정보를 설정한다.
  구체적으로는 컨트롤 비트의 FIN 비트에 1을 설정하고, IP 담당부분에 의뢰하여 클라이언트에 송신해 달라고 한다.
• 이와 동시에 서버측의 소켓에 연결 끊기 동작에 들어갔다는 정보를 기록한다.
• 클라이언트측에서는 서버에서 FIN에 1을 설정한 TCP 헤더가 도착하면 클라이언트측의 프로토콜 스택은 자신의 소켓에 서버측이 연결 끊기 동작에 들어갔다는 것을 기록한다.
• 그리고 FIN을 1로 설정한 패킷을 받은 사실을 알리기 위해 ACK를 반송하고, 이것이 끝나면 애플리케이션에 데이터를 가지러 올 때까지 기다린다.
• 잠시 후 애플리케이션이 read를 호출해 데이터를 가지러 오는데, 그러면 데이터를 건네지 않고 서버에서 보낸 데이터를 전부 수신 완료했다는 사실을 클라이언트측의 애플리케이션(브라우저)에게 알린다.
• 웹의 동작은 서버가 응답을 반송하면 끝나도록 규칙으로 정해져 있으므로 서버에서 보낸 데이터를 전부 수신 완료하면 클라이언트도 종료한다.
• 그래서 클라이언트측의 애플리케이션도 close를 호출하여 데이터 송,수신 동작을 끝낸다.
• 그러면 클라이언트측의 프로토콜 스택은 서버측과 마찬가지로 FIN 비트에 1을 설정한 TCP 헤더를 만들고 IP 담당 부분에 의뢰해 서버에 송신한다. 서버에서 ACK 번호가 돌아오면 서버와의 대화가 끝난다.

2. 소켓을 말소한다.

• 서버와의 대화가 끝나면 소켓을 사용하며 서버와 대화할 수 없게 된다. 이때 소켓은 필요 없지만, 바로 소켓을 말소하지 않고 잠시 기다린 후 소켓을 말소한다.
• 오동작을 막기 위해 기다리는 것이다.
• 만약 클라이언트가 FIN을 송신했는데 ACK가 돌아오지 않으면 어떨까? 다시 한번 FIN을 보내면 된다.
• 이때 이미 서버의 소켓이 말소되어 있다면 기록되어 있던 제어 정보가 없어지므로 소켓에 할당되어 있던 포트 번호도 몇 번인지 알 수 없다.
• 이 시점에서 다른 애플리케이션이 소켓을 작성하면 새 소켓에 같은 포트 번호가 할당될 수 있다.
• 이렇게 해서 같은 포트 번호의 소켓이 만들어진 상태에서 클라이언트가 다시 보낸 FIN이 도착하면 오작동이 발생한다.
• 이러한 오동작을 막기위해 소켓을 즉시 말소하지 않고 잠시 기다리는 이유다.
• 일반적으로 보통 몇 분 정도 기다리고 나서 소켓을 말소한다.

3. 데이터 송,수신 동작을 정리한다.

최초의 동작은 소켓을 작성한다.

보통은 먼저 서버측에서 애플리케이션이 동작하기 시작했을 때 소켓을 만들고 이것을 접속 대기 상태로 만든다.

클라이언트측은 사용자가 무언가 조치를 취하여 서버에 액세스하는 동작이 시작될 때 일반적으로 패킷을 작성하지만,

이 단계에서는 아직 패킷을 주고 받지 않는다.

 

소켓을 만들면 클라이언트에서 서버를 향해 접속 동작을 실행한다.

1. 먼저 클라이언트가 SYN을 1로 만든 TCP 헤더를 만들어 서버로 보낸다. 여기에는 시퀀스 번호의 초기값, 윈도우의 값도 기록되어 있다.
2. 서버에 도착하면 서버에서 SYN을 1로 만든 TCP 헤더가 돌아온다.
   이 TCP 헤더에도 시퀀스 번호와 윈도우가 기록되어 있고, TCP 헤더를 받은 것을 나타내는 ACK 번호도 기록되어 있다.
3. 이것이 클라이언트에 도착하면 TCP 헤더를 받은 것을 나타내는 ACK 번호를 기록한 TCP 헤더를 클라이언트가 서버에 보낸다.
   이것으로 접속 동작은 끝나고 데이터 송, 수신 단계에 들어간다.
4. 웹의 경우는 서버에 리퀘스트 메시지를 보내는 것 부터 시작하는데, TCP는 이것을 적당한 크기의 조각으로 분할하고 TCP 헤더를 맨 앞에 부가하여 서버에 보낸다. TCP 헤더에 송신 데이터가 몇 번째 바이트부터 시작되는지를 나타내는 시퀀스 번호가 기록되어 있다.
5. 이것이 서버에 도착하면 서버는 ACK 번호를 클라이언트에 반송한다.
6. 클라이언트가 리퀘스트 메시지를 보냈으므로 서버는 응답 메시지를 반송한다.
   응답 메시지도 위와 같이 TCP가 적당한 크기로 분할하고 TCP 헤더를 붙이고, 시퀀스 번호를 기록해서 보낸다.
7. 그러면 클라이언트에서 응답 메시지를 받았다고 ACK 번호를 서버에게 반송한다.
   이것으로 데이터 송,수신 동작이 끝나고 연결 끊기 동작에 들어간다.
8. 웹의 경우는 서버에서 연결 끊기 동작에 들어간다. 서버가 FIN을 1로 만든 패킷을 보낸다.
9. 그럼 이것을 받았다는 것을 나타내기 위해 ACK 번호를 서버에게 반송한다.
10. 그러면 역방향으로 FIN을 1로 만든 TCP 헤더를 서버에게 보낸다.
11. 그럼 서버가 받았다는 것을 알려주기 위해 ACK 번호를 클라이언트에게 반송한다.
    그리고 잠시 후 소켓이 말소한다.

05. IP와 이더넷의 패킷 송, 수신 동작

1. 패킷의 기본

• 패킷 은 헤더와 데이터의 두 부분으로 구성된다.
• 헤더에는 수신처를 나타내는 주소 등의 정보 제어가 들어있는데, 이 부분은 택배의 전표와 동일하다.
  의뢰한 데이터는 화물의 내용물에 해당한다.
• 먼저 패킷의 송신처가 되는 기기가 패킷을 만드는데, 헤더에는 적절한 제어 정보를 기록하고,
  데이터 부분에는 얼마간의 데이터를 넣은 후 패킷을 가장 가까운 중계 장치에 송신한다.
• 그러면 패킷이 가장 가까운 중계 장치에 도착하고, 중계 장치는 도착한 패킷의 헤더를 조사해 패킷의 목적지를 판단한다.
  이때 어느 수신처가 어느 방향에 있는지에 대한 정보를 기록한 표와 같은 것을 사용한다.
• 즉 패킷의 헤더에 기록되어 있는 수신처와 표에 등록된 내용을 결합하여 패킷의 수신처가 표의 어느 부분에 해당하는지 찾아내고,
  거기에 등록되어 있는 내용에서 패킷의 목적지를 판단한다.
• 이와 같은 방법으로 패킷을 중게하면 다시 그 다음의 중계 장치에서 패킷이 도착한다.
  이렇게 해서 차례로 패킷을 중계하며 최종적으로 수신처의 기기에 패킷이 도착한다.
• 또한 송신처에서 수신처를 향해 패킷을 보내면 수신처에서 송신처를 향한 회답 패킷이 돌아온다.
• 소신처와 수신처의 기기를 묶어서 '엔드노드'라고 부른다.

서브넷은 라우터와 허브라는 두 종류의 패킷 중계 장치에서 다음과 같은 역할을 분담하면서 패킷을 운반한다.

• 라우터가 목적지를 확인하여 다음 라우터를 나타낸다. 라우터는 IP의 규칙에 따라 패킷을 운반한다.
  즉 다음과 같이 정리할 수 있다. IP가 목적지를 확인하여 다음 IP의 중계 장치를 나타낸다.
• 허브가 서브넷 안에서 패킷을 운반해 다음 라우터에 도착한다. 허브는 이더넷의 규칙에 따라 패킷을 운반한다.
  즉 다음과 같이 정리할 수 있다. 서브넷 안에 있는 이더넷이 중계 장치까지 패킷을 운반한다.

좀 더 구체적으로 말하면 TCP/IP 패킷에는 두 개의 헤더가 붙어있다.

그리고 다음과 같이 역할을 분담해 패킷을 운반한다.

• MAC 헤더: 이더넷용 헤더
• IP 헤더: IP용 헤더

먼저 송신처에서 패킷의 목적지가 되는 액세스 대상 서버의 IP 주소를 IP 헤더의 수신처에 기록한다.

이제 패킷의 목적지가 분명해지므로 IP는 이 수신처가 어느 방향에 있는지를 조사하고, 그 방향에 있는 다음 라우터를 조사한다.

다음 라우터를 발견하면, 거기에 패킷을 도착하도록 이더넷에 의뢰한다.

이때 다음 라우터에 할당된 이더넷의 주소(MAC 주소)를 조사하고, 그것을 MAC 헤더에 기록한다.

이렇게 해서 의뢰를 받은 이더넷에게 어느 라우터에 패킷을 도착하면 좋은지를 전달한다.

 

패킷을 송신하면 이더넷의 원리에 따라 움직이는 허브에 도착한다. 

허브에는 패킷의 목적지를 판단하기 위한 표(이더넷용 표)와 같은 것이 있어서

이더넷의 헤더의 수신처 정보와 표를 결합해서 패킷의 목적지를 판단하여 중계 한다.

 

그러면 패킷은 다음 라우터에 도착한다.

라우터에는 IP용 표가 있으므로 이것과 IP 헤더의 수신처를 결합하면 다음에 어느 라우터에 패킷을 중계하면 좋을지가 결정된다.

그리고 다음 라우터에 패킷을 건네주기 위해 라우터의 MAC 주소를 조사하고, 이것을 MAC 헤더에 기록한다.

그러면 MAC 헤더를 바꾸어 쓰고, 패킷을 다음 라우터에 송신한다.

 

참고로 이더넷의 역할은 무선 LAN, ADSK, FTTH 등 다른 것으로 대체가 가능하다.

2. 패킷 송, 수신 동작의 개요

• IP 담당 부분은 패킷을 상대에게 송출만 하기 때문에 그 뒤에 상대가 있는 곳까지 패킷을 운반하는 것은 허브나 라우터 같은 네트워크 기기의 역할이 되므로 IP 담당 부분은 패킷을 운반하는 동작 전체에서 입구 부분에 불과하다.
• 패킷 송,수신 동작의 출발점은 TCP 담당 부분이 IP 담당 부분에 패킷을 의뢰하는 곳부터 시작된다.
  의뢰 동작을 할 TCP 담당 부분은 데이터의 조각에 TCP 헤더를 부가한  것을 IP 담당 부분에게 건네준다.
• 이것이 패킷에 들어가는 내용이 되고, 이와 동시에 통신 상대의 IP 주소를 나타낸다. 
• 이 의뢰를 받은 IP 담당 부분은 내용물을 한 덩어리의 디지털 데이터로 간주하고, 그 앞에 제어 정보를 기록한 헤더를 부가한다. 
  부가하는 것은 IP 헤더와 MAC 헤더다.
• IP 헤더는 IP 프로토콜에 규정된 규칙에 따라 IP 주소로 표기된 목적지까지 패킷을 전달할 때 사용하는 제어 정보를 기록한 것이다.
• MAC 헤더는 이더넷 등의 LAN을 이용해 가장 가까운 라우터까지 패킷을 운반할 때 사용하는 제어 정보를 기록한 것이다.
• 이제 만든 패킷을 네트워크용 하드웨어에 건넨다. 우리는 LAN 어댑터로 가정한다. 패킷은 LAN 어댑터에 의해 전기나 빛의 신호 상태로 바귀어 케이블에 송출된다.
• 신호나 허브나 라우터 등의 중계 장치에 도착하고, 중계 장치가 있는 곳까지 패킷을 전달한다.
• 상대에게 패킷이 도착하면 거기에서 회답이 돌아오는데 회답의 가정도 위와 같이 동일하다.
• 중요한 점은 IP가 패킷을 송,수신하는 동작은 제어 패킷이든지, 데이터의 패킷이든지 패킷의 역할에 상관 없이 모두 같다.

3. 수신처 IP 주소를 기록한 IP 헤더를 만든다.

• IP 담당 부분은 TCP 담당 부분에서 패킷 송, 수신 의뢰를 받으면 IP 헤더를 만들어 TCP 헤더의 앞에 붙인다.
• IP 헤더 항목에서 제일 중요한 것은 수신처 IP 주소다. TCP 담당 부분에서 통지된 통신 상대의 IP 주소로 설정한다.
• IP는 스스로 수신처를 판단하지 않고 애플리케이션이 지정한 상대에게 패킷을 송신할 뿐이므로 애플리케이션이 IP 주소를 잘못 지정해도 그 IP 주소를 그대로 IP 헤더에 설정한다.
• 송신처 IP 주소도 설정한다.
  IP 주소는 컴퓨터에 할당되는 것이 아니라 LAN 어댑터에 할당되므로 송신처가 되는 LAN 어댑터의 IP 주소로 할당한다.
• 패킷을 건네줄 상대를 판단하는 방법은 라우터가 IP용 표를 사용하여 다음 라우터를 결정하는 동작과 같다.
• 이 IP용 표를 경로표라고 부르며,
  소켓에 기록된 수신처 IP 주소를 경로표의 'Network Destination' 항목과 비교해 경로표의 어느행에 해당하는지 찾아낸다.
• 이렇게 해서 해당하는 행을 찾아낸 다음에는 'Interface' 항목과 'Gateway' 항목을 조사한다.
• 'Gateway' 항목은 LAN 어댑터 등의 네트워크용 인터페이스를 나타내고,
  인터페이스에서 패킷을 송신하면 상대에 패킷을 전해줄 수 있다는 의미다.
• 또한 'Gateway' 항목에는 다음 라우터의 IP 주소를 기록하게 되어서 IP 주소를 가진 라우터에게 패킷을 건네주면 라우터가 목적지에 패킷을 중계해 준다.
• 경로표에는 넷마스크도 등록되어 있다. 넷마스크가 0.0.0.0인 경우에는 소위 기본 게이트웨이를 나타낸다.
  즉 다른 곳에 일치하는 것이 없으면 이 행이 해당하는 것으로 간주한다.
• 이렇게 해서 어느 LAN 어댑터에서 패킷을 송신해야 하는지 알고 나서 LAN 어댑터에 할당되어 있는 IP 주소를 IP 헤더의 송신처 IP 주소로 설정한다.
• 프로토콜 번호라는 필드에도 값을 설정한다. 여기에는 패킷에 들어간 내용물이 어디에서 의뢰받은 것인지를 나타내는 값을 설정한다.
• TCP에서 의뢰받은 내용물이라면 06, UDP에서 의뢰받은 것이면 17이라는 식이다.

4. 이더넷용 MAC 헤더를 만든다.

• IP 헤더를 만들었으면 IP 담당 부분의 앞에 MAC 헤더를 붙인다.
• 이더넷은 TCP/IP와 다른 구조로 패킷의 수신처를 판단하며, 이 구조를 따르지 않으며 이더넷 패킷을 운반할 수 없다.
  이더넷의 수신처 판단 구조로 사용하는 것이 MAC 헤더다.
• MAC 헤더의 맨 앞에 있는 수신처 MAC 주소와 그 다음의 송신처 MAC 주소는 각각 패킷을 전달하는 상대와 패킷을 송신한 송신처의 MAC 주소를 나타낸다. 또한 MAC 주소는 48비트다.
• 3개의 이더 타입이라는 항목은 IP 헤더의 프로토콜 번호와 비슷하다.
• 이더넷의 경우 이더 타입까지가 MAC 헤더이고, 그 뒤에 이어지는 것이 패킷의 내용물로 생각한다.
  그리고 내용물이 무엇인지를 이더 타입으로 나타낸다.
• 이더넷의 내용물은 IP나 ARP라는 프로토콜의 소켓이며, 각각에 대응하는 값이 규칙으로 정해져 있으므로 여기에 값을 기록한다.
• MAC 헤더는 이 3가지를 설정한다. 먼저 이더 타입 필드에는 IP 프로토콜을 나타내는 0800이라는 값을 설정한다.
• 다음에는 송신처 MAC 주소인데 이는 자체의 LAN 어댑터의 MAC 주소를 설정한다.
• 수신처 MAC 주소는 좀 복잡하다. 사실 건네는 시점에서 아직 누구에게 패킷을 건네주어야 할지 모른다.
• 따라서 먼저 건네줄 상대를 조사해야 한다. 이것은 경로표에 기록되어 있다.
  경로표에서 찾은 일치하는 행의 'Gateway' 항목에 기록되어 있는 IP 주소의 기기가 패킷을 건네줄 상대가 된다.
• 아직 이 시점에서는 상대의 MAC 주소를 모르므로 IP 주소에서 MAC 주소를 조사하는 동작을 실행한다.

5. ARP로 수신처 라우터의 MAC 주소를 조사한다.

• 여기에서 사용하는 것이 ARP다.
• 이더넷에는 연결되어 있는 전원에게 패킷을 전달하는 브로드캐스트라는 방식이 있다.
• 이것을 이용해 우리가 찾을 IP를 물어보는 패킷을 이더넷 전체에게 보낸다.
• 그러면 해당하는 기기가 MAC 주소를 응답으로 보낸다.
• 그러면 이제 MAC 송신처 주소에 응답으로 돌아온 MAC 주소를 적으면 된다.
• 패킷을 보낼 때마다 이 동작을 하면 ARP의 패킷이 불어나므로 한 번 조사한 결과는 ARP 캐시라는 메모리 영역에 보존하여 다시 이용된다.
• 즉 패킷을 송신할 때 우선 ARP 캐시를 조사하여 거기에 상대의 MAC 주소가 저장되어 있으면 ARP를 조회하지 않고 ARP 캐시에 보존되어 있는 값을 사용한다.
• 캐시에 저장되어 있지 않다면 ARP로 조회한다. 
• 캐시를 너무 오래 남겨두면 오류가 발생할 수 있으므로 몇 분이 경과하면 삭제한다.
• ARP를 사용해 수신처 MAC 주소도 적어서 MAC 헤더를 완성했다.

6. 이더넷의 기본

• 이더넷은 다수의 컴퓨터가 여러 상대와 자유롭게 적은 비용으로 통신하기 위해 고안된 통신 기술이다.
• 크게 이더넷의 원형, 리피터 허브를 사용한 이더넷, 스위칭 허브를 사용한 이더넷을 살펴본다.
• 이더넷의 원형 트렁크 케이블과 트랜시버 케이블로 이루어진다. 쉽게 말해 전체가 케이블로 이루어진다.
  동작 방식은 케이블을 통해 신호가 전체에 흘렀다.
  수신처 MAC 상대에게 패킷 전달을 위해 패킷에 수신처 주소를 써둔다.
• 트렁크 케이블이 리피터 허브로 바뀌었지만, 신호가 전원에게 전달되는 기본적인 성질은 그대로다.
• 스위칭 허브를 사용한 형태가 현재의 이더넷이다. 전원에게 신호가 전달된다는 성질이 변했으며 수신처 MAC 주소로 나타내는 원하는 기기가 존재하는 부분에만 신호가 흐르고 다른 곳에는 신호가 흐르지 않게 되었다.
• 수신처 MAC 상대에게 패킷이 전달된다는 점은 변하지 않았다.
• 이더넷도 IP와 마찬가지로 패킷의 내용물은 보지 않으므로 이더넷의 송, 수신 동작은 TCP 동작 단계에 상관 없이 모든 것에 공통이다.

7. IP 패킷을 전기나 빛의 신호로 변환하여 송신한다.

• IP가 만든 패킷은 메모리에 기억된 디지털 데이터이므로 이것을 상대에게 보낼 수 없다.
• 그래서 디지털 데이터를 전기나 빛의 신호로 변환하여 네트워크의 케이블에 송출하는데 이것이 송, 수신 동작의 본질이다.
• 이 동작을 실행하는 것이 LAN 어댑터인데, LAN 어댑터는 단독으로는 동작하지 않습니다.
• LAN 어댑터를 제어하려면 LAN 드라이버 소프트웨어가 필요하기 때문이다. 이는 모든 하드웨어 공통이다.
• LAN 어댑터도 다른 하드웨어와 마찬가지로 초기화 작업이 필요하다. 초기화 작업 중에 이더넷 특유의 작업도 있다. 
• 이더넷의 송, 수신 동작을 제어하는 MAC라는 회로에 MAC 주소를 설정하는 것이다.
• LAN 어댑터의 ROM에는 전 세계에서 중복되지 않도록 일원화되어 관리되는 MAC 주소가 제조할 때 기록되어 있다.
• LAN 어댑터에 기록된 MAC 주소는 LAN 드라이버가 MAC 회로에 설정한다.

8. 패킷에 3개의 제어용 데이터를 추가한다.

• LAN 드라이버는 IP 담당 부분에서 패킷을 받으면 그것을 LAN 어댑터의 버퍼 메모리에 복사한다.
• 복사를 마친 후 패킷을 송신하도록 MAC 회로에 명령을 보내면 MAC 회로의 작업이 시작된다.
• MAC 회로는 먼저 송신 패킷을 버퍼 메모리에서 추출하고 맨 앞에는 프리앰블과 스타트 프레임 딜리미터라는 두 개의 데이터를,
  맨 끝에는 프레임 체크 시퀀스라는 오류 검출용 데이터를 부가한다.
• 프리앰블은 송신하는 패킷을 읽을 때의 타이밍을 잡기 위한 것으로 크기는 56비트다.
  수신측은 신호를 수신할 때 이 파형에서 타이밍을 판단한다.
• 디지털 데이터를 전기 신호로 나타낼 때는 0과 1 비트 값을 전압이나 전류의 값에 대응시킨다.
• 진짜 신호에서는 각 비트의 구분을 나타내는 보조선이 있으므로 각 비트의 구분이 어디까지인지 판단하면서 전압이나 전류의 값을 읽어야 한다.
• 그러나 1과 0이 이어지면 신호의 변화가 없어져서 비트 구분을 할 수 없게 된다.
• 이 문제를 해결하기 위한 방법이 데이터를 나타내는 신호와는 별도로 비트 구분을 나타내는 클록이라는 신호를 보내는 방법이다.
• 클록 신호가 아래에서 위로 변화할 때 데이터 신호의 전압이나 전류의 값을 읽고 이것을 0과 1로 대응시킨다.
• 그러나 클록이 틀어져 버릴 경우에는 문제가 발생한다.
• 데이터 신호와 클록 신호를 합성하여 한 개의 신호로 만들면 이 문제를 해결할 수 있다. 그리고 이것을 송신측에서 수신측으로 보낸다.
• 그러면 클록 신호를 사용해 데이터 신호를 추출할 수 있다.
• 이때 클록 신호의 타이밍을 판단하는 것이 중요한데, 이 때 프리앰플을 사용한다.
• 스타트 프레임 딜리미터는 패킷의 시작을 나타내는 표시가 된다.
• FCS는 패킷을 운반하는 도중에 잡음 등의 영향으로 파형이 흐트러져 데이터가 변한 경우 이것을 검출하기 위해 사용한다.
• 패킷을 운반하는 도중에 잡음 등의 영향으로 내용의 데이터가 변하면 수신측에서 계산한 FCS가 송신할 때 계산한 것과 다른 값이 된다. 이러한 불일치를 통해 데이터가 변화한 사실을 검출한다.

9. 허브를 향해 패킷을 송신한다.

• 프리앰블, 스타트 프레임 딜리미터, FCS의 세 가지를 부가하면 케이블에 송출하는 패킷이 완성된다.
• 리피터 허브를 사용했하면서 송신 동작을 수행하면 전이중 모드와 반이중 모드가 있다.
• 반이중 모드는 신호의 충돌을 피하기 위해 케이블에 다른 기기가 송신한 신호가 있는지 조사하고,
  신호가 흐르고 있다면 그것이 끝날 때까지 기다린다.
• 그리고 신호가 정지했거나 애초부터 신호가 흐르지 않으면 송신 동작을 개시한다.

10. 돌아온 패킷을 받는다.

• 리피터 허브를 이용한 반이중 동작의 이더넷에서는 1대가 송신한 신호가 리피터 허브에 접속된 케이블 전부에 흘러간다.
• 즉 자신뿐만 아니라 누군가가 신호를 보내면 그것이 전부 수신 신호선에서 흘러온다. 
  그러므로 수신 동작은 이러한 신호를 전부 받아들이는 것부터 시작한다.
• 신호의 맨 앞에는 프리앰블이 있으므로 파형에서 타이밍을 계산해 스타트 프레임 딜리미터가 나오면
  그 다음부터 디지털 데이터로 변환하여 동작을 개시한다.
• 이 동작은 PHY(MAU) 회로에서 MAC 회로쪽으로 진행한다. 이후 차례대로 데이터를 변환해 버퍼 메모리에 저장한다.
• 그리고 신호의 마지막에 이르르면 맨 끝의 FCS를 검사한다.
• 문제가 없다면 MAC 헤더의 수신처 MAC 주소를 조사해 LAN 어댑터를 초기화할 때 설정한 자체의 MAC 주소와 비교한 후 이것이 자신에게 오는 것인지 판단한다.
• 다른 곳에갈 패킷은 폐기하고, 자신에게 온 패킷은 받아 버퍼 메모리에 저장한다.
• 이렇게 MAC 회로가 할 일이 끝나면 패킷을 수신한 사실을 컴퓨터 본체에 통지한다.
• 이 통지는 인터럽트라는 구조를 사용한다. 운영체제 인터럽트 개념과 동일하다.
• 쉽게 말해 컴퓨터 본체가 실행하고 있는 작업에 끼어들어 LAN 어댑터쪽에 주의시킨다.

11. 서버의 응답 패킷을 IP에서 TCP로 넘긴다.

• 서버에서 반송된 패킷의 타입은 0800이므로 LAN 드라이버는 TCP/IP의 프로토콜 스택에 패킷을 건넬 것이다.
• IP 담당 부분은 IP 헤더 부분부터 조사해 포맷에 문제가 없는지 확인하고, 수신처 IP 주소를 조사한다.
• 만약 수신처 IP 주소가 자신의 주소와 다르면 오류가 있는 것이다.
• 이와 같은 오류가 발생하면 IP 담당 부분이 ICMP라는 메시지를 사용해 통신 상대에게 오류를 통지한다.
• IP 프로토콜에는 조각 나누기, 프래그먼테이션이라는 기능이 있다.
• 만약 분할된 패킷이라면 IP 담당 부분은 분활된 패킷들을 원래 패킷으로 되돌릴 수 있어야 한다.
• 분할된 패킷은 IP 헤더에 있는 플래그라는 항목을 보면 알 수 있다.
• 수신 패킷이 분할된 것이면 IP 담당 부분이 내부의 메모리에 일시적으로 보관한다.
• 그리고 IP 헤더에 있는 ID 정보에 같은 값을 가진 패킷이 도착하기를 기다리고, 분할된 패킷은 ID 정보의 값이 모두 같은 값인 패킷이므로 이것을 참조한다.
• 또한 프래그먼트 오프셋이라는 항목에는 패킷이 원래 어느 위치에 있었는지를 나타내는 정보가 들어있다.
• 이러한 정보를 바탕으로 분할된 패킷이 전부 도착하기를 기다렸다가 패킷을 원래의 모습으로 되돌리는 동작을 리어셈블링이라고 한다.
• 이것으로 IP 담당 부분의 역할은 끝나 패킷을 TCP 담당 부분에 넘긴다.

06. UDP 프로토콜을 이용한 송, 수신 동작

• 수정 송신이 필요없는 데이터의 송신은 UDP가 효율적이다. 회신을 위한 수신 확인 응답이 필요 없기 때문이다.
• DNS 서버에 대한 조회 등 제어용 짧은 데이터는 UDP를 사용한다.
• 음성 및 동영상 데이터에서 UDP를 사용한다.

 

참고자료

 

컴퓨터 네트워킹 하향식 접근 제 7판

성공과 실패를 결정하는 1%의 네트워크 원리

https://product.kyobobook.co.kr/detail/S000000559964