[Network] 네트워크 원리(2) - TCP/IP의 데이터를 전기 신호로 만들어 보낸다

개요

---

성공과 실패를 결정하는 1% 네트워크 원리를 공부하고 정리한 글이다.

Chapter 2 - 프로토콜 스택과 LAN 어댑터 탐험

 

 

STORY 1 | 소켓을 작성한다.

---

1-1) 프로토콜 스택의 내부 구조

• 인터넷에서 데이터를 운반할 때는 데이터를 작게 나누어 패킷이라는 형태로 운반한다.
• 패킷을 통신 상대까지 운반하는 것이 IP의 주 역할이다.
• IP 안에는 ICMP와 ARP라는 프로토콜을 다루는 부분이 포함되어 있다.
  • ICMP: 패킷 운반 통제 및 제어용 메시지 통제
  • ARP: 이더넷의 MAC 주소

 

1-2) 소켓의 실체는 통신 제어용 제어 정보

소켓은 개념적인 것이어서, 실체가 없다. 굳이 말하자면 제어 정보, 즉 제어 정보가 기록된 프로토콜 스택 내부의 메모리 영역이다.

• 제어 정보에는 통신 상대의 IP 주소, 포트 번호, 통신 동작의 상태 등이 있다.
• 소켓에는 응답이 돌아오는지의 여부와 송신 동작 후의 경과 시간 등이 기록되어 있다. → 이 정보를 보고 포기하거나 다시 보내는 동작을 실행해야 하기 때문
• netstat 명령어

 

1-3) 소켓을 호출했을 때의 동작

브라우저가 소켓이나 connect같은 소켓 라이브러리의 부품을 호출했을 때, 프로토콜 스택의 내부는 어떻게 움직일까?

• 브라우저에서 gethostnyname같은 걸로 요청하면…
• TCP/IP layer에서 소켓 생성하기
  • 소켓의 제어 정보를 기록할 메모리 영역 확보하기
  • 소켓을 작성한 직후에는 송수신 동작이 시작되지 않은 상태이므로, 초기 상태임을 나타내는 정보 기록
• 소켓을 만들고, 디스크립터를 애플리케이션에 알려주기
• 애플리케이션은 앞으로 통신할 때 이 디스크립터를 활용

 

 

STORY 2 | 서버에 접속한다.

---

2-1) 서버에 접속 == 소켓에 정보를 기록

소켓을 만든 직후는 아무것도 기록되어 있지 않다. 이 상태로는 송신 의뢰가 와도 제대로된 통신을 할 수가 없다. → 소켓을 호출하여 만드는 것만으로는 프로토콜 스택에는 아무것도 전달되지 않기 때문에 IP 주소나 port 번호같은 내용을 프로토콜 스택에 알리는 동작(접속 동작)이 필요하다.

• 접속을 위해.. 즉, 통신을 위한 정보를 만들기 위해
  1. 통신 상대와 제어 정보를 주고받아 소켓에 필요한 정보를 기록한다. (ex. 클라이언트 측의 IP 주소나 포트 번호를 서버 측에 알리는 것)
• 접속 동작에서 주고받는 제어 정보는 규칙이 정해져 있다.

 

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

TCP 헤더 내용

 

• 통신 동작 전체에서 어떤 정보가 필요한지 검토하는 TCP 프로토콜의 사양으로 규정되어있다.
• 이 항목들은 고정화되어 있어, 송수신/연결끊기/대화할 때마다 각 단계에서 이 제어 정보를 사용한다.
• 즉, 데이터를 나눈 패킷마다, 패킷의 가장 앞부분인 헤더에 이 내용이 부가되어 있다.
  • 제어 정보만 있는 패킷은 뒷부분 데이터가 없고 제어 정보가 적힌 헤더만 존재

 

2-3) 접속 동작의 실체

애플리케이션이 socket 라이브러리의 connect를 호출하는 것부터 시작된다.

connect(<디스크립터>, <서버 IP>, <서버 PORT>)

 

접속 동작의 순서

1. 클라이언트의 TCP 담당 부분에 ip와 port 전달 → 서버의 TCP 담당 부분에 전달
   • 포트번호: 클라이언트 소켓의 수신처가 되는 서버측의 소켓을 지정할 수 있는 관문
2. 포트를 통해 접속 소켓을 확실히 하고, 컨트롤 비트인 SYN = 1 세팅
3. 위와 같이 TCP 헤더를 만들고 IP 담당 부분에 건넴
4. IP 담당 부분이 패킷 송신 동작 실행
5. 네트워크를 통해 패킷을 서버에 보냄
6. 서버측의 IP 담당 부분이 TCP 담당 부분에 건네어, 헤더 조사
7. 수신처 소켓 즉, 포트 번호를 찾아서 필요한 정보를 기록하고 상태 변경(접속 동작 진행중)
8. 응답 … 응답을 보낼 때도 마찬가지로, TCP 헤더 만들고, ACK = 1 세팅
9. 응답을 받은 클라이언트는 또 다시 TCP 분석하고, SYN = 1 확인 후 소켓에 접속 완료를 나타내는 제어 정보를 기록
10. 서버에게 응답을 잘 받았다는 ACK = 1 반송

⇒ 이 접속 동작이 끝나면 비로소 데이터를 송수신할 수 있는 상태가 된다. 파이프와 같은 것으로 소켓이 연결되었다고 생각하면 된다!

 

 

STORY 3 | 데이터를 송수신한다.

---

서버와 연결이 완료되면 애플리케이션 단에서 write 요청을 보낸다. 이때 프로토콜 스택은 송신 데이터의 내용을 알지 못한다. 데이터 길이만큼만 바이너리 데이터가 1바이트씩 차례로 나열되어 있다고 알고 있다.

 

3-1) 송수신 시, 내부 송신용 버퍼 메모리 활용

• 프로토콜 스택은 애플리케이션으로부터 받은 데이터를 일단 내부 송신용 버퍼 메모리에 저장한다.⇒ OS의 종류나 버전에 따라 버퍼의 수용 가능한 크기, 데이터를 보내는 시점이 다르다.
• ⇒ 송신 요청이 올 때마다 작은 소켓을 네트워크 상에 흘려보내면 네트워크 이용 효율이 저하되므로, 어느정도 데이터를 저장하고 나서 송수신 동작을 한다.

 

3-2) 일반적으로 데이터를 보내는 시점은?

📌 2 가지 기준

 

1. MTU로 판단한다. 

• MTU(Maximum Transmission Unit): 패킷 하나로 운반가능한 데이터 최대 길이
• MSS(Maximum Segment Size): MTU에서 TCP/IP의 헤더를 뺀 부분 ⇒ 즉, 페이로드 부분

 

 

 

2. 타이밍

애플리케이션의 송신 속도가 느려지는 경우 → 프로토콜 스택 내부의 타이머 활용

 

 

*두 기준의 trade-off를 잘 생각해야 한다. MTU에 너무 집중하면 네트워크 이용효율이 높지만 서비스/통신 지연 가능성이 생기고, 2번을 기준으로 타이머를 너무 짧게 잡으면 느려짐은 없어도 네트워크 이용 효율이 좋지 않아진다. → 이에 대한 명확한 기준은 없고 OS/프로토콜 스택 개발자에 달려있는 상황이다.

 

*타이밍 제어는 옵션으로 지정 가능하다.

 

 

3-3) 데이터가 크면 분할해서 보내기

 

블로그나 게시판 등에서 긴 문장을 투고하는 등 한 개의 패킷에 다 담기지 않는 경우 → 송신 버퍼에 저장된 데이터는 MSS 길이를 초과하므로, 맨 앞부터 차례대로 MSS 크기에 맞게 분할하고 분할한 조각을 한 개씩 패킷에 넣어 송신한다.

 

 

3-4) ACK를 통해 패킷이 도착했는지 확인

• 송신 측이 한 데이터를 N 바이트씩 나누어서 그 시작점을 시퀀스 넘버로 설저하고, 시퀀스 번호와 데이터 크기를 수신측에 같이 전송 → 수신측은 송신측으로받은 시퀀스 넘버 단위로 데이터를 받았다는 OK 사인을 전송
  1. → seq: 1, 1460 byte
  2. ← ACK 1461
  3. → seq: 1461, 1460 byte
  4. ← ACK 1462

그런데, TCP의 송수신 동작은 양방향이므로, 두 가지의 데이터 흐름이 있다. (→, ←) 이에 대응하기 위해서 클라이언트 측에서도 ACK를 전송, 서버측에서도 시퀀스 넘거를 전송해준다.

 

• 먼저 시퀀스 넘버를 양쪽에서 산출하고, 접속 동작을 할 때 서로 통지한다. → 이때도 서로 ACK 반송
• 시퀀스 번호와 ACK 번호가 준비되면 데이터 송수신 동작에 들어간다.
• 최초 클라이언트가 요청하면 서버에서 ACK를 반송하는 방식으로 데이터를 주고받는다.

→ TCP는 상대의 데이터 수신을 확인할 때까지 송신용 패킷을 버퍼 메모리에 저장해둔다. 만약 이에 대응하는 상대의 ACK가 오지 않으면 다시 이 데이터를 보내야 하기 때문이다.

 

→ TCP의 이러한 통신 방식으로 인해, 송수신을 TCP에만 맡겨두면 LAN 어댑터, 라우터 등 어디에서도 오류 검출을 할 필요가 없다. 네트워크의 어디에서 오류가 발생하더라도 TCP의 통신 특성만으로 회복 처리를 취할 수 있기 때문이다. 단, 도중에 케이블이 분리되거나 서버가 다운되는 등의 문제가 생기면 TCP가 아무리 데이터를 다시 보낸다고 해도 해결할 수 없다. 이럴 때에는 TCP가 몇 번 다시 보낸 후 회복의 전망이 없는 것으로 보고 데이터 송신 동작을 강제로 종료하고 애플리케이션에 오류를 통지한다.

 

3-5) ACK의 대기시간은?

ACK의 반송이 지연되는 상황은 보통 혼잡인 경우가 많으므로, 너무 자주 다시 데이터를 보내면 혼잡을 더 악화시킬 수 있다. 하지만 대기 시간을 너무 길게 잡으면 패킷을 다시 보내는 동작이 지연돼서 속도 저하의 원인이 될 수 있다. (→ 아까 내부 송신용 버퍼에 저장하고 데이터를 보내는 시점을 설정하는 것과 비슷한.. trade-off)

 

• 동적으로 TCP 대기시간 변경이 가능하다.
  • ACK 번호가 돌아오는 시간을 기준으로 대기 시간을 판단한다. 데이터 송신 동작을 실행하고 있을 때 항상 ACK가 돌아오는 시간을 계측해 두고, 조정한다.

 

3-6) 윈도우 제어 방식으로 패킷 송수신 효율 높이기

• 수신 측의 능력을 초과할 만큼 데이터를 한 번에 쏟아내버리면?수신 가능한 데이터의 최대양을 윈도우 크기라고 한다.
  • 감당 가능한 데이터의 양을 정해서 송신(클라이언트)측에 알려준다. 클라이언트는 데이터를 보낼 때 보낸 데이터의 크기와 용량을 비교하면서, 가능한 남은 영역이 0이 되면 송신을 중지한다.
• 윈도우 통지 타이밍
  • 송신측은 한 번 통지를 받으면 송신한 데이터와 비교하여 스스로 남은 값을 계산할 수 있다. 그러므로, 수신 측에서 애플리케이션에 데이터를 건네주고 수신 버퍼의 빈 영역이 늘어났을 때 송신측에 통지해야 한다.
• ACK와 윈도우 통지 패킷을 줄이고 효율적인 통신을 하는 방법
  1. 소켓을 바로 보내지 않고 잠시 기다린다. 이때 다음 통지 동작이 일어나면 양쪽을 상승 시켜서 함께 하나의 패킷으로 묶어 보낸다.
  2. ACK 번호 통지가 여러 번 연속해서 일어나면 최후의 것만 통지한다. (도중의 것 생략 가능)

 

 

STORY 4 | 서버에서 연결을 끊어 소켓을 말소한다.

---

 

 

• 서로 FIN, ACK를 주고 받는다. (데이터 전송이 끝난 측에서 먼저 FIN 전송)
• 소켓이 말소되면 모든 정보가 없어진다. → 이때 애플리케이션이 다른 소켓을 작성하면 말소된 포트 번호를 사용할 수 있기 때문에 마지막 FIN에 대한 ACK는 어느정도 시간을 두고 말소한다.

 

STORY 5 | IP 패킷 송수신 동작

---

큰흐름

TCP 담당 부분에서 패킷을 바이너리로 전달받은 IP는 IP헤더, MAC 헤더 만들어서 이더넷에 보내고, 이더넷은 이 IP 패킷(디지털 데이터)를 전기 신호/빛으로 변환해서 케이블로 데이터를 흘려보낸다. 모든 소켓관련 내용은 위에서 다 해주기 때문에 이더넷은 모든 기기에 공통적으로 행동한다.

 

5-1) 앞에서 프로토콜스택.. TCP로부터 의뢰받은 IP는 어떻게 동작할까?

송신처에서 소켓을 가장 가까운 중계처(라우터 등)로 전송하면, 소켓 헤더에 저장된 정보 + 중계처의 표(수신처/가까운 또다른 중계처의 방향에 대한 정보)를 통해 데이터를 전송한다.

• 허브: 이더넷의 규칙에 따라 패킷 운반
• 라우터: IP의 규칙에 따라 패킷 운반

■ 실제로 송신처 컴퓨터부터 중간 중계장치들(라우터, 허브 등)을 거치는 과정

1. 송신처에서 패킷이 가려는 서버의 IP 주소를 IP 헤더의 수신처에 기록한다.
2. 패킷의 목적지가 분명해지므로, IP는 이 수신처가 어느 방향에 있는지 + 라우터를 조사한다.
3. 이어서 다음 방향의 라우터 조사한다.
4. 다음 방향의 라우터로 패킷을 보내도록 이더넷에 의뢰한다.
5. 다음 라우터에 할당된 이더넷의 주소(MAC 주소)를 이더넷이 알려주고, 이를 MAC 헤더에 기록한다.
6. 이더넷 추천 경로에 따라 허브에 도착한다.
7. 허브에서는 수신처 정보와 표를 결합해서 목적지를 판단 및 중계한다.
8. 패킷은 다음 라우터에 도착한다.
9. 라우터에는 IP용 표가 있으므로, 이것과 IP 헤더의 수신처를 결합해서 다음 중계지(라우터)를 결정한다.
10. 해당 라우터의 MAC 주소를 헤더에 붙여서 송신한다.

 

 

5-2) 패킷 송수신 동작의 개요

■ 패킷 송수신은 TCP 담당부분이 IP 담당 부분에 패킷을 의뢰하는 것부터 시작된다.

• TCP 담당 부분은 [TCP 헤더 + 데이터 조각]을 IP 부분에 건네준다.

■ TCP 담당으로부터 송신 의뢰를 받은 IP 담당 부분은 추가적인 헤더를 붙여, 네트워크용 HW에 건네준다.

• IP 헤더: IP 프로토콜에 규정된 규칙에 따라 패킷을 목적지에 보낼 때 사용하는 제어 정보
• MAC 헤더: 이더넷 등의 LAN을 사용하여 가장 가까운 라우터까지 패킷을 운반할 때 사용하는 제어 정보

■ 네트워크 HW, 이더넷 등에서는 0과 1로 구성된 디지털 데이터를 받아서 전기 신호 상태로 바꾸어 케이블에 송출한다.

• 신호는 허브나 라우터 등의 중계 장치에 도착하고, 이 장치가 상대가 있는 곳까지 패킷을 전달한다.

📌 IP 패킷 송수신 동작은 패킷의 역할에 관계없이 모두 같다. IP 담당 부분은 TCP 담당으로부터 받은 데이터를 그냥 하나의 바이너리 데이터로 간주하고 내용물에 대해서는 전혀 관심이 없다. 당연히 TCP의 동작 단계도 신경쓰지 않는다. 어떤 형식이든 의뢰받은 내용물을 패킷의 모습으로 만들어 상대에게 송신 및 전달하기만 할 뿐이다.

 

 

5-3) IP 헤더

• 가장 중요한 것은 수신처(목적지) IP 주소(애플리케이션에서 통지된 통신 상대의 IP 주소)다. IP는 애플리케이션이 지정한 것이 잘못되었어도 그대로 송신한다. 애플리케이션 측 책임으로 간주하기 때문이다
• 송신처 IP 주소는 사실 컴퓨터에 할당되는 것이 아니라 LAN 어댑터에 할당되므로, 복수의 LAN 어댑터가 있을 경우 한 대의 컴퓨터에 할당된 IP가 여러 개다.
  • 따라서 어느 IP 주소를 송신처 주소로 설정할 지 판단해야 한다. → 이 판단은 패킷을 건네주는 상대의 라우터를 결정하는 것과 같다.
  • 상대 라우터가 결정되면 LAN 어댑터에서 패킷을 송신해야 하는지 결정되고, LAN이 결정되면 IP 주소가 결정되기 때문이다.

 

■ 패킷을 건네주는 상대의 라우터를 판단하는 방법?

• 라우터가 IP용 표를 사용하여 다음 라우터를 결정하는 것과 같다.
• route print 명령어
  • interface: 네트워크용 인터페이스
  • Gateway: 다음 라우터의 IP 주소
  • 넷마스크: 기본 gateway
  • 프로토콜 번호: 어디에서 의뢰받은 것인지 설정(TCP: 06, UDP: 17)

 

5-4) 이더넷용 MAC 헤더 - IP 헤더 만들고, MAC 헤더 만들어 붙이기

■ IP 헤더를 통해 목적지 주소를 알 수 있지만, 이더넷에는 TCP/IP 개념이 통용되지 않는다. 따라서 이더넷 패킷을 운반하기 위해서 수신처를 판단할 때 MAC 헤더를 사용한다.

 

 

• 송신처 MAC 주소: 하나의 48비트, LAN 어댑터의 MAC 주소 설정
  • MAC 주소는 LAN을 제조할 때 그 안의 ROM에 기록한다.
• 수신처 MAC 주소: 패킷을 건네주는 상대의 MAC 주소
  • 패킷을 건네줄 상대의 주소는 경로표 ‘Gateway’에 기록되어 있다.
• 이더 타입: 패킷의 내용물이 무엇인지 나타냄
  • 이더타입까지가 MAC 헤더이고, 그 뒤에 이어지는 것은 패킷의 내용물
  • 이더넷의 내용물은 IP, ARP같은 프로토콜의 소켓이며, 각각에 대응하는 값이 규칙적으로 정해져 있으므로 여기에 값을 기록한다.

 

5-5) ARP로 라우터의 MAC 주소 조사한다.

상대가 자신과 같은 네트워크에 존재하면 단순히 브로드캐스트로 “OO라는 IP 주소 있는 분?” 이렇게 찾을 수 있다. 그럼 "저요~"하는 상대방의 MAC 주소를 MAC 헤더에 설정하면 끝이다. 

 

■  ARP 캐시

• 패킷을 보낼 때마다 "있으신 분 - 저요" 동작을 반복하면 ARP 패킷이 불어나기 때문에 ARP 캐시라는 메모리 영역에 보존하여 재사용한다.
• ARP 캐시를 먼저 확인하고, 없는 경우에만 브로드캐스트한다.
• 캐시에 저장된 내용은 일정 시간이 지나면 삭제된다. (오류 방지를 위해)

■ 이러한 MAC 주소/헤더를 붙이는 것까지 IP 담당 부분의 역할이다.

• LAN 어댑터에 건네주기 전에 IP 담당 부분에서 패킷을 완성하면 LAN은 전송만 하면 되기 때문에 IP 쪽이 담당한다!

 

 

STORY 6 | 이더넷 패킷 송수신 동작

---

5-6) 이더넷의 기본

 

 

 

 

 

• MAC 헤더의 수신처 MAC 주소를 가진 상대에게 패킷을 전달한다.
• 송신처 MAC 주소로 송신처를 나타낸다.
• 이더 타입으로 패킷의 내용물을 나타낸다.
• ‘이더넷’이라는 하나의 사양에 기초하여 동작하기 때문에 클라이언트, 라우터 등 상관없이 모든 기기에 공통적으로 적용된다.

 

 

 

 

 

 

 

 

5-7) IP로부터 받은 패킷(디지털 데이터)을 전기/빛의 신호로 변환하여 송신한다.

■ IP 패킷으로 받은 디지털 데이터를 전기 신호로 변환하는 것은 LAN 어댑터다.

• 하지만 LAN 어댑터는 단독으로 일할 수 없고, 이를 제어하는 LAN 드라이버 소프트웨어가 필요하다. (모든 HW의 공통.. 이를 제어하는 SW가 필요함)
• 전원 공급 → OS 시동 → 드라이버가 어댑터 초기화(MAC 주소 설정) → OK

■  IP한테 패킷을 받으면 LAN 어댑터의 버퍼 메모리에 복사 후, 패킷을 송신하도록 MAC 회로에 명령을 보낸다.

 

 

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

1. 프리앰블(preeamble): 송신하는 패킷을 읽을 타이밍을 잡기 위한 것. → 101110… 이라는 비트 패턴을 신호로 바꾸면 파형이 일정한 모습을 갖는다. 수신측은 신호를 수신할 때 이 파형에서 타이밍을 잡는다.
2. 스타트 프레임 딜리미터: 패킷의 시작을 나타내는 표시
3. FCS(Frame Check Sequence): 운반하는 도중 파형이 흐트러져 데이터가 변한 경우, 이를 검출하기 위해서 사용한다. 계산의 바탕이 된 데이터 값이 1비트라도 변화하면 달라진 값을 취하도록 고안이 되어 있다. 패킷을 운반하는 도중 잡음 등의 영향으로 데이터가 변하면, 수신측에서 계산한 FCS가 송신측과 달라진다. 이 차이를 통해 전달 과정에서 문제가 발생했음을 파악한다.

 

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

위 세 가지를 부가하면, 케이블에 송출하는 패킷이 완성된다. 드디어 신호를 송신할 수 있는 상태가 된다!

 

■ [반이중 모드] 이더넷 구조를 따라 패킷이 변환되어 케이블까지 흘러가는 과정

• 케이블에 다른 기기가 송신한 신호가 흐르고 있는지 조사하고, 끝날 때까지 기다린다. (신호 충돌 방지)
• MAC 회로가 프리앰블의 맨 앞부터 1비트씩 차례로 전기 신호로 변환한다.
  • 이때 디지털 데이터를 신호로 변환하는 속도가 전송 속도다. →만약 1초 동안 10MB 디지털 데이터를 신호로 변환하여 보낸다면 전송률은 10MiB/초
• 이후 변환된 전기 신호를 PHY(MAU) 신호 부분에 보낸다. 이 전기 신호를 다시 케이브렝 송출하는 형식으로 변환하여 송신한다. 즉, PHY는 MAC 회로가 송신한 전기 신호의 형식을 케이블 형시긍로 변환하기 위한 변환회로다!
  • PHY는 송신 동작만 하는 것이 아니라 수신 신호선에서 신호가 흘러들어오는지 감시한다.

*이더넷은 송신한 신호가 상대에게 완전히 도착했는지 확인하지 않는다. 이더넷은 사양에서 기기와 기기 사이를 연결하는 케이블 길이를 100m 이내로 정한다. 그래서 오류가 좀처럼 발생하지 않는다.

 

■ PHY는 송신 동작만 하는 것이 아니라 수신 신호선에서 신호가 흘러들어오는지 감시한다.

• 이때, 리피터 허브(b)를 사용한 반이중 모드의 경우에는 서로의 신호가 뒤섞여서 분간할 수 없는 상태(충돌)가 된다.
• 그러면 송신 동작을 중단하고 충돌 사실을 다른 기기에 알리는 재밍 신호를 흘린다. 재밍 신호를 흘리고 잠시 기다렸다가 다시 송신 동작을 시도한다.
• 스위칭 허브(c)를 사용한 전이중모드는 송수신을 동시에 실행하면서 충돌은 일어나지 않는다.

 

 

5-10) 돌아온 패킷을 받는다.

■ 리피터 허브를 이용한 반이중 동작의 이더넷에서의 동작 과정

• 1대가 송신한 신호가 리피터 허브에 접속된 케이블 전부에 흘러간다.
• 프리앰블, 스타트 프레임 딜리미터가 나오면 그 다음 비트부터 디지털 데이터로 변환한다. (그러니까 송신의 거꾸로)
  1. 먼저 PHY회로에서 신호를 공통 형식으로 변환하여 MAC 회로에 보낸다.
  2. MAC 회로에서 신호를 맨앞부터 차례대로 디지털 데이터로 변환하여 버퍼 메모리에 저장한다.
  3. 신호의 마지막에서 FCS 검사 ➡️ 잡음 확인
• FCS에 문제가 없으면 MAC 헤더의 나의 MAC 주소와 비교하여 자신에게 오는 것인지 판단한다.
• 자신에게 오는 게 맞으면 인터럽트를 통해 컴퓨터 본체에 통지한다.

■ 인터럽트의 동작 과정

LAN 어댑터가 확장 버스 슬롯 부분에 있는 인터럽트용 신호선에 신호 전송 → 본체는 이 신호를 받고 CPU가 실행하고 있던 작업을 일시적으로 보류 → OS 내부 kernel 모드 실행 → LAN 드라이버 호출 → LAN 드라이버가 LAN 어댑터를 제어하여 송수신 동작 실행

 

 

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

■ LAN은 TCP/IP(0800)임을 확인하고 IP 부분으로 올려 보낸다. IP 담당 부분은 헤더 부분부터 조사하여 문제가 없는지 확인한다.

• 만약 수신처 IP 주소가 잘못 적혀 있다면, ICMP라는 메시지를 사용하여 통신 상대에게 오류를 통지한다. (181p의 다양한 메시지 종류)
• IP 헤더의 플래그를 확인해서 이 패킷이 만약 분할된 패킷(IP Fragmentation)이라면 IP 담당 부분 내부의 메모리에 일시적으로 보관한다. 그리고 같은 frag를 가진 패킷이 도착하기를 기다리고, 모든 패킷이 도착하면 각각의 패킷마다 붙어있는 offset 순서대로 원래의 모습으로 되돌린다. 이 되돌리는 동작을 리어셈블링이라고 한다.

■ 리어셈블링이 끝난 패킷을 TCP 담당 부분에 전송한다.

• 송수신처의 ip, port를 통해 해당 소켓을 찾아 적절한 통신을 한다. (소켓에는 통신 진행 상태가 기록되어 있다.)
• 만약 연결 끊기(FIN같은) 패킷이라면 애플리케이션에게 통지하거나 응답 패킷을 반송한다.