소켓을 작성한다.
프로토콜 스택의 내부 구성
프로토콜 스택 : OS에는 내장된 네트워크 제어용 소프트웨어
LAN 어댑터 : 네트워크용 하드웨어
구성 요소
애플리케이션
네트워크 애플리케이션 : 브라우저, 웹 서버, 메일 서버 등 프로그램이 여기에 해당된다. 여기부터 아래로 향하여 데이터 송수신 등의 일을 의뢰한다.
Socket 라이브러리 : 애플리케이션의 아랫부분에 Socket 라이브러리가 있으며 그 안에는 리졸버가 내장되어 있다.
OS
Transport Layer : TCP, UDP, 프로토콜을 사용하여 데이터를 송수신 한다.
Network Layer : IP프로토콜을 사용하여 패킷 송수신 동작을 제어한다.
ICMP : 패킷을 운반할 때 발생하는 오류를 통지하거나 제어용 메시지를 통지할 때 사용
ARP : IP주소에 대응하는 이더넷의 MAC 주소를 조사할 때 사용
드라이버 소프트웨어
LAN 드라이버 : LAN 어댑터의 하드웨어를 제어
하드웨어
LAN 어댑터 : 실제 송수신 동작을 실행
소켓의 실체는 통신 제어용 제어 정보
소켓의 역할
프로토콜 스택은 내부에 제어 정보를 기록하는 메모리 영역을 가지고 있으며 여기에 통신 동작을 제어하기 위한 제어 정보를 기록한다. 프로토콜 스택은 소켓에 기록된 제어 정보를 참조하면서 동작한다.
ex) 통신 상대의 IP주소, 포트 번호, 통신 동작 진행 상태
소켓은 개념적인 것이어서 실체가 없으므로 제어 정보 또는 제어 정보를 기록한 메모리 영역이 소켓의 실체이다.
PID : Process ID의 약자로 각 프로그램을 식별하기 위해 OS가 할당하는 번호
Socket을 호출했을 때의 동작
- 애플리케이션이 소켓 생성을 요청하면 프로토콜 스택은 소켓을 만듭니다. 프로토콜 스택의 첫 번째 작업은 소켓에 대한 메모리 영역을 확보하는 것입니다. 소켓의 제어 정보를 저장할 메모리 영역은 처음부터 존재하지 않으므로, 먼저 확보해야 합니다. 이 시점에서 소켓은 초기 상태를 나타내는 제어 정보를 메모리 영역에 기록합니다.
- 소켓이 생성되면, 프로토콜 스택은 소켓을 식별하는 디스크립터를 애플리케이션에 전달합니다.
- 디스크립터를 받은 애플리케이션은 데이터 송수신 동작을 프로토콜 스택에 요청할 때 디스크립터를 사용합니다. 소켓에 저장된 정보를 통해 프로토콜 스택은 어떤 소켓인지 알 수 있습니다. 이렇게 하면 애플리케이션이 통신 상대의 정보를 일일이 전달받을 필요가 없어집니다.
서버에 접속한다.
소켓을 만든 직후는 소켓에 아무 정보도 기록되지 않았기 때문에 통신 상대가 누구인지 모른다.
socket을 호출하여 소켓을 만드는 동작만으로는 프로토콜 스택에는 아무 것도 전달되지 않는다.
그러므로 서버의 IP주소나 포트 번호를 프로토콜 스택에 알리는 동작이 필요하다.
클라이언트에서 서버측에 전달하면 서버측의 프로토콜 스택도 클라이언트 정보를 가질 수 있다.
접속 동작 흐름
1. 통신 상대와 제어 정보를 주고 받는다.
2. 소켓에 필요한 정보를 기록하여 데이터 송수신이 가능한 상태로 만든다.
3. 데이터를 저장할 버퍼 메모리를 확보한다.
데이터 송수신 동작을 실항핼 때는 송수신하는 데이터를 일시적으로 저장하는 메모리 영역이 필요한데 이 메모리 영역을 "버퍼 메모리" 라고 부른다.
제어 정보에는 크게 두가지 있다.
1. 헤더에 기입되는 정보
2. 소켓에 기록되는 정보
접속 동작 실제 흐름
1. Socket 라이브러리의 connect를 호출한다.
2. 소켓에 서버측 IP주소와 포트 번호를 쓰고 TCP 담당 부분에 전달한다.
3. 데이터 송수신 동작의 개시를 나타내는 제어 정보를 기록한 헤더를 만든다. 여기에는 송신처와 수신처의 포트 번호가 기록된다. 컨트롤 비트인 SYN이라는 비트를 1로 만들어 IP에 전달한다.
4. 패킷 송신 동작을 실행하고 네트워크를 통해 패킷이 서버에 도착하면 서버측 IP 담당 부분이 이것을 받아 TCP에 건네준다.
5. 헤더를 바탕으로 수신처 포트 번호에 해당하는 소켓을 찾아내고 여기에 필요한 정보를 기록하고 접속 동작이 진행중이라는 상태가 된다.
6. 과정이 끝나면 TCP 담당 부분은 응답을 돌려 보낸다. 클라이언트와 마찬가지로 제어 정보를 기록한 헤더를 만들고 ACK 컨트롤 비트를 1로 만든다.
7. ACK비트로 패킷이 도착한 것을 확인한다.
8. TCP 헤더를 IP에 건네주어 클라이언트에 반송하도록 의뢰한다.
9. 클라이언트에 패킷이 돌아오고 IP 담당 부분을 경유해 TCP 담당 부분에 도착한다. 이때 TCP 헤더를 조사하여 서버측 접속 동작이 성공했는지 확인한다. SYN이 1이면 접속 성공이다.
10. 소켓에 서버의 IP주소나 포트 번호 등과 함께 소켓에 접속 완료를 나타내는 제어 정보를 기록한다.
11. 패킷이 도착한 것을 서버에 알리기 위해 ACK 비트를 1로 만든 TCP 헤더를 반송한다.
소켓은 데이터를 송수신 할 수 있는 상태가 됬는데 이때 파이프와 캍은 것으로 소켓이 연결되었다고 생각할 수 있는데 이 파이프와 같은 것을 커넥션이라고 한다.
또한 데이터 송수신 동작을 계속하고 있는 동안 close호출하여 연결을 끊을 때까지 계속 존재한다.
이렇게 해서 커넥션이 이루어지면 프로토콜 스택의 접속 동작이 끝나므로 connect의 실행이 끝나면서 애플리케이션을 제어할 수 있게 된다.
데이터를 송수신한다.
프로토콜 스택에 HTTP 리퀘스트 메시지를 넘긴다
프로토콜 스택의 중요한점
1. 프로토콜 스택은 받은 데이터의 내용이 무엇이 쓰여있는지 알지 못한다.
2. 프로토콜 스택은 받은 데이터를 곧바로 송신하는 것이 아니라 일단 자체의 내부에 있는 송신용 버퍼 메모리 영역에 저장하고 애플리케이션이 다음 데이터를 건네주기를 기다린다.
송신을 의로할 때 애플리케이션에서 프로토콜 스택에 건네주는 데이터의 길이는 전부 한꺼번에 송신의로하는 경우도 있고 세분하여 송신 의뢰하는 경우도 있다.
세분하여 송신하는 방법은 네트워크 이용 효율이 저하되므로 어느정도 데이터를 저장하고 나서 송수신 동작을 한다.
송신은 2가지 경우로 판단한다.
1. 데이터 크기
MTU라는 매개변수를 바탕으로 판단한다.
MTU : Maximum Transmission Unit의 줄인말으로 한 패킷이 운반할 수 있는 디지털 데이터의 최대 길이로 이더넷에서는 보통 1500바이트가 된다.
MSS : Maximum Segment Size로 MTU에는 패킷 앞 부분에 헤더가 포함되어 있으므로 헤더를 제외하고 한 패킷으로 운반할 수 있는 TCP 데이터의 최대 길이
2.. 타이밍
애플리케이션의 송신 속도가 느려지는 경우 MSS에 가깝게 데이터를 저장하면 송신 동작이 지연된다.
따라서 버퍼에 데이터가 모이지 않아도 프로토콜 스택의 내부 타이머가 일정 시간이 경과하면 패킷을 송신한다.
프로토콜 스택에만 맡긴다면 좋지 않은 일이 생길 수도 있기 때문에 애플리케이션측에서 송신 타이밍을 제어하는 여지도 남겨두었다.
데이터가 클 때는 분할하여 보낸다
한 개의 패킷에 들어가지 않을 만큼 긴 것도 있다.
이 경우 송신 버퍼에 저장된 데이터는 MSS의 길이를 초과하므로 다음 데이터를 기다릴 필요가 없다.
따라서 송신 버퍼에 들어있는 데이터를 맨 앞부터 차례대로 MSS 크기에 맞게 분할하고 분할한 조각을 한 개씩 패킷에 넣어 송신한다.
ACK 번호를 사용하여 패킷이 도착했는지 확인한다.
패킷 평균 왕복 시간으로 ACK 번호 대기 시간을 조정한다
타임아웃 값은 ACK 번호가 돌아오는 것을 기다리는 시간입니다. 네트워크 혼잡으로 인해 ACK 번호의 지연이 발생할 수 있으므로 적절한 대기 시간을 설정해야 합니다. 너무 짧은 대기 시간은 재전송으로 인한 혼잡을 악화시키고, 너무 긴 대기 시간은 속도 저하의 원인이 됩니다. TCP는 대기 시간을 동적으로 변경하는 방법을 사용하며, ACK 번호가 돌아오는 시간을 기준으로 대기 시간을 조절합니다. 지연이 발생하면 대기 시간을 늘리고, 빠른 반응이 있으면 대기 시간을 줄입니다. 이렇게 함으로써 TCP는 네트워크 상황에 적절하게 대응합니다.
윈도우 제어 방식으로 효율적으로 ACK 번호를 관리한다.
윈도우 제어 방식은 연속적으로 패킷을 보내어 시간 낭비를 줄이는 방법입니다. 수신측의 TCP는 수신용 버퍼 메모리를 사용해 데이터를 일시적으로 보관하고 처리합니다. 하지만 수신 버퍼가 넘치게 되면 데이터가 손실되고 오류가 발생할 수 있습니다. 윈도우 제어 방식에서는 수신 가능한 데이터 양을 송신측에 통지하고, 송신측은 이를 초과하지 않도록 조절합니다. 수신 처리가 완료되면, 수신 가능한 데이터 양이 증가하고, 이 정보는 TCP 헤더의 윈도우 필드를 통해 송신측에 알려집니다. 윈도우 사이즈는 수신 가능한 데이터 양의 최대값을 의미한다.
ACK 번호와 윈도우를 합승한다.
ACK 번호와 윈도우를 각각 별도의 패킷으로 보내면 보내는 패킷이 많아져서 효율성이 저하된다.
수신측은 ACK 번호나 윈도우를 통지할 때 소켓을 바로 보내지 않고 잠시 기다린다.
기다리는 사이에 다음 동작이 일어나면 양쪽을 한 개의 패킷으로 묶어서 보낸다.
이렇게 하면 패킷을 줄일 수 있다.
HTTP 응답 메시지를 수신한다.
프로토콜 스택 수신 과정
1. 수신한 데이터 조각과 TCP 헤더 내용을 조사하여 도중에 데이터가 누락되었는지 검사한다.
2. 문제가 없으면 ACK 번호를 반송한다.
3. 데이터 조각을 수신 버퍼에 일시 보관하고 조각을 연결하여 데이터를 원래 모습으로 복원한 후 애플리케이션에 건네준다.
4. 애플리케이션에 데이터를 건네주고 나서 타이밍을 가늠하여 윈도우를 송신측에 통지한다.
서버에서 연결을 끊어 소켓을 말소한다.
데이터 보내기를 완료했을 때 연결을 끊는다.
연결 끊기 과정
1. 서버 측에서 소켓 라이브러리의 close 함수를 호출합니다.
2. 서버 측 프로토콜 스택은 TCP 헤더를 생성하고, FIN 비트를 설정한 후 클라이언트에 전송합니다. 이 때, 서버 측 소켓에 연결 종료 정보가 기록됩니다.
3. 클라이언트는 FIN 비트가 설정된 TCP 헤더를 받고, 소켓에 서버 측 연결 종료 정보를 기록합니다.
4. 클라이언트는 서버에 ACK 번호를 반환하며, 애플리케이션이 데이터 요청을 할 때까지 대기합니다.
5. 서버로부터 모든 데이터가 전송되었음을 클라이언트 애플리케이션에 알립니다. 웹 동작 규칙에 따라 서버에서 모든 데이터 전송이 완료되면, 클라이언트도 종료합니다.
6. 클라이언트 프로토콜 스택은 FIN 비트가 설정된 TCP 헤더를 생성하여 서버에 전송합니다.
7. 서버로부터 ACK 번호를 받게 되면, 연결 종료가 완료됩니다.
소켓을 말소한다.
패킷이 손실될 때, 일정 시간 동안 재전송이 진행됩니다. 몇 분이 지나면 회복이 불가능하다고 판단하여 재전송을 중지하고, 소켓은 이 시간이 지난 후에 말소됩니다.
ACK 번호가 소멸되어 FIN이 두 번 보내지는 경우, 동일한 포트 번호가 새로운 애플리케이션에 할당될 수 있습니다. 이로 인해 새로운 소켓으로 FIN이 전송되어 오동작이 발생할 수 있기 때문에 소켓을 즉시 말소하지 않고 일정 시간 기다린다.
데이터 송수신 동작 정리
IP와 이더넷의 패킷 송수신 동작
패킷 전송 과정
1. 송신처 기기가 패킷을 생성한다.
2. 접근 대상 서버의 IP 주소를 IP 헤더의 수신처에 기록하고 데이터 부분에 데이터를 추가한다.
3. IP는 수신처의 방향을 확인하여 그 방향의 다음 라우터를 조사합니다.
4. 해당 라우터에 패킷을 전달하도록 이더넷에 요청한다. 이 때, 다음 라우터의 이더넷 주소를 확인하고 MAC 헤더에 기록한다.
5. 패킷을 전송한다.
6. 패킷이 이더넷 원리에 따라 허브에 도착한다.
7. 허브에 패킷의 목적지를 판단하는 이더넷용 표를 사용하여 패킷을 중계한다.
8. 다음 라우터에 도착합니다.
9. 라우터에 있는 IP용 표로 IP 헤더의 수신처를 결합하여 어느 라우터로 패킷을 중계할지 결정한다.
10. 패킷을 전달하기 위해 라우터의 MAC 주소를 확인하고, 이를 MAC 헤더에 기록한 후 패킷을 다음 라우터로 전송한다.
11. 허브를 거쳐 다음 라우터에 패킷이 도착한다.
12. 이 과정을 반복하여 패킷이 목적지에 도착한다.
13. 수신처에서 송신처로 회답 패킷을 전송합니다.
엔드노드
이렇게 송신처였던 기기가 다음 시점에는 수신처가 되므로 송신처와 수신처를 명확하게 구분하지 않고 묶어서 "엔드노드" 라고 부른다.
TCP 담당 부분
패킷의 송수신 동작의 출발점은 TCP 담당 부분이 IP 담당 부분에 패킷 송신을 의뢰하는 곳부터 시작된다.
TCP 담당 부분은 데이터 조각에 TCP 헤더를 부가한 것을 IP 담당 부분에 건네주는 동시에 통신 상대의 IP 주소를 나타낸다.'
IP 담당 부분
의뢰를 받은 IP 담당 부분은 앞에 제어 정보를 기록한 IP 헤더와 MAC 헤더를 부가해 만든 패킷을 네트워크용 하드웨어에 건네준다.
IP 헤더 : IP 프로토콜에 규정된 규칙에 따라 IP 주소로 표시된 목적지까지 패킷을 전달할 때 사용하는 제어 정보
MAC 헤더 : 이더넷 등의 LAN을 사용하여 가장 가까운 라우터까지 패킷을 운반할 때 사용하는 제어 정보
네트워크용 하드웨어 담당 부분
하드웨어는 이더넷이나 무선 LAN 등을 말한다.
이 설명에서는 LAN 어댑터라 통칭하기로 한다.
LAN 어댑터에 건네줄 때의 패킷의 모습은 0이나 1의 비트가 이어진 디지털 데이터라고 생각하면 되고 이것이 LAN 어댑터에 의해 전기나 빛의 신호 상태로 바뀌어 케이블에 송출된다.
신호는 허브나 라우터 등의 중계 장치에 도착하고 중계 장치가 상대가 있는 곳까지 패킷을 전달한다.
상대에게 패킷이 도착하면 회답이 돌아온다.
회답 패킷이 돌아오는 과정
1. 케이블에서 신호의 모습을 한 패킷이 들어온다.
2. LAN 어댑터에서 디지털 데이터의 모습으로 되돌린다.
3. 디지털 데이터의 패킷을 IP 담당 부분에 건네준다.
4. IP 담당 부분이 MAC 헤더와 IP 헤더의 뒤에 TCP 헤더와 데이터 조각을 TCP 담당 부분에게 건네준다.
5. TCP 담당 부분이 처리한다.
IP 헤더
IP 헤더에는 수신처의 IP 주소가 기록되어 패킷을 전달해야 할 위치를 알려줍니다. 여기에는 TCP에서 알린 상대방의 IP 주소가 포함됩니다. IP는 수신처를 스스로 판단하지 않고, 애플리케이션에서 지정한 대상에게 패킷을 전송합니다. 애플리케이션에서 잘못된 IP 주소를 지정하면, IP 헤더에 그대로 설정됩니다.
송신처 IP 주소도 포함됩니다. 이는 일반적으로 컴퓨터에 할당된 IP 주소입니다. 하지만 컴퓨터에 할당된 IP 주소를 무조건적으로 믿을 수 없습니다. LAN 어댑터의 개수에 따라 IP 주소가 여러 개가 될 수 있기 때문입니다. 따라서 어떤 LAN 어댑터를 사용하여 패킷을 전송해야 하는지 결정해야 합니다.
경로표
프로토콜 스택의 IP 부분과 라우터에서 패킷을 송수신하는 부분은 IP 규칙에 따라 동작하므로, 같은 IP용 표인 경로표를 사용합니다.
소켓에 기록된 수신처 IP 주소를 경로표의 Network Destination 항목과 비교하여 해당 행을 찾습니다. 예를 들어 IP 주소가 10.10.1.166이면 10.10.1과 일치하므로 세 번째 행에 해당합니다. 이렇게 IP 주소의 왼쪽 부분이 일치하는 것을 찾습니다.
Interface 항목과 Gateway 항목을 확인합니다. Interface 항목은 네트워크용 인터페이스(어댑터 등)를 나타내고, 인터페이스에서 패킷을 전송하면 상대방에게 도달한다는 의미입니다. Gateway 항목은 다음 라우터의 IP 주소를 기록하여, 해당 IP 주소를 가진 라우터에 패킷을 전달하면 라우터가 목적지로 패킷을 중계해 준다는 것을 나타냅니다.
경로표의 맨 위 행에는 목적지와 넷마스크가 0.0.0.0으로 등록되어 있습니다.
이것은 기본 게이트웨이를 의미하며, 다른 일치하는 항목이 없으면 이 행을 사용합니다.
이를 통해 어떤 LAN 어댑터에서 패킷을 전송해야 할지 결정하고, LAN 어댑터에 할당된 IP 주소를 송신처 IP 주소로 설정합니다.
프로토콜 번호 필드
프로토콜 번호 필드에는 패킷의 내용이 어떤 프로토콜에서 요청한 것인지를 나타냅니다.
TCP에서 요청한 경우 06(16진수 표기)이고, UDP에서 요청한 경우 17(16진수 표기)입니다.
이 값들은 규칙에 따라 결정됩니다.
기타 항목에도 값을 기입하지만 큰 영향이 없다.
이더넷용 MAC 헤더를 만든다
IP 헤더를 만들었으면 IP 담당 부분의 앞에 MAC헤더를 붙인다.
IP 헤더에 수신처 IP 주소에 패킷을 전달하는 목적지로 패킷을 어디로 운반해야 하는지 알 수 있다.
하지만 이더넷에는 TCP/IP 개념이 통용되지 않는다. TCP/IP와 다른 MAC 헤더로 판단한다.
MAC 헤더는 맨 앞에 있는 수신처 MAC 주소와 송신처 MAC 주소는 각각 패킷을 전달하는 상대와 패킷을 송신한 송신처의 MAC 주소를 나타낸다.
IP 헤더에 있는 수신처 IP 주소 및 송신처 IP 주소와 같은 역할을 가지고 있다.
IP 주소와 MAC 주소의 차이점
IP 주소가 32비트이지만 MAC 주소는 48비트라는 부분이 다르다.
IP 주소는 몇 동 몇 번지 같은 주소를 보는 그룹화 개념이지만 MAC은 하나의 값이다.
이더 타입
IP 헤더의 프로토콜 번호와 비슷하게 내용물이 무엇인지를 이더 타입으로 나타낼 수 있다.
이더넷의 경우 이더 타입 까지가 MAC 헤더이고 그 뒤에 이어지는 것이 패킷의 내용물로 생각한다.
이더넷의 내용물은 IP나 ARP라는 프로토콜 소켓이며 각각에 대응하는 값이 규칙으로 정해져 있으므로 여기에 값을 기록한다.
MAC 헤더를 만들 때는 이더 타입, 송신처 MAC 주소, 수신처 MAC 주소 3가지를 기록하면 된다.
송신처 MAC 주소는 LAN 어댑터를 제조할 때 그 안에 ROM에 기록되므로 여기에 기록되어 있는 값을 읽어와 MAC 헤더로 설정한다.
수신처 MAC 주소는 경로표에서 찾은 일치하는 행의 Gateway 항목에 기록되어 있는 IP 주소의 기기가 패킷을 건네줄 상대가 된다.
패킷을 건네줄 상대를 알았으면 IP 주소에서 MAC 주소에서 MAC 주소를 조사하는 동작을 실행한다.
ARP로 수신처 라우터 MAC 주소 조사방법
1. 이더넷에는 연결되어 있는 전원에게 패킷을 전달하는 브로드캐스트라는 구조가 있으므로 IP 주소를 가지고 있는지 전원에게 조사한다.
2. 해당 IP를 가지고 있는 곳에서 MAC 주소를 응답한다.
3. 상대가 자신과 같은 네트워크에 존재하면 이것으로 MAC 주소를 알아낼 수 있으므로 MAC 주소를 MAC 헤더에 설정하여 만든다.
ARP 캐시
패킷을 보낼 때마다 동작을 하면 ARP 패킷이 불어나기 때문에 한 번 조사한 결과는 ARP 캐시라는 메모리 영역에 보존하여 다시 이용한다.
하지만 ARP 캐시에 저장된 MAC 주소를 언제까지나 사용하면 문제가 발생할 수 있기 때문에 유효 기간을 설정한다.
이 삭제 동작은 ARP 캐시의 내용이 유효한지의 여부와 관계 없이 몇 분이 경과한 것을 무조건 삭제한다.
이더넷 기본
이더넷은 다수의 컴퓨터가 여러 상대와 자유롭게 적은 비용으로 통신하기 위해 고안된 통신 기술로 다음 그림과 같이 발전해왔다. 이더넷도 IP와 마찬가지로 패킷의 내용물은 보지 않으므로 송수신 동작은 TCP 동작 단계에 상관 없이 모든 것이 공통이다.
IP 패킷을 전기나 빛의 신호로 변환하여 송신한다.
디지털 데이터를 전기나 빛의 신호로 변환하여 네트워크 케이블에 송출하는데 이 동작을 실행하는 것이 LAN 어댑터이다.
LAN 어댑터는 단독으로는 동작하지 않고 LAN 드라이버 소프트웨어가 필요하다.
또한 LAN 어댑터의 구조는 제조 업체나 기종에 따라 달라지므로 LAN 드라이버는 LAN 어댑터 제조 업체가 준비한 전용 제품을 사용한다.
LAN 어댑터 구조
LAN 어댑터는 전원을 공급받아도 즉시 사용할 수 있는 상태가 아닙니다.
초기화 작업이 필요한데, 이 작업은 OS가 시동될 때 LAN 드라이버에 의해 수행됩니다.
하드웨어 이상 검사와 초기 설정 등 LAN 어댑터 외의 하드웨어와 관련된 초기화 작업이 많지만, 이더넷에서는 특유의 MAC 회로에 MAC 주소를 설정하는 작업이 필요합니다.
전 세계적으로 중복되지 않도록 일원화하여 관리되는 MAC 주소는 LAN 어댑터의 ROM에 기록되어 있습니다.
제조 시점에 기록되며, LAN 드라이버가 이 주소를 읽어 MAC 회로에 설정해야 합니다.
이 과정을 통해 MAC 회로는 자신에게 할당된 MAC 주소를 알게 됩니다.
전원을 공급할 때 자동으로 유효한 것처럼 보이는 MAC 주소는 실제로 LAN 드라이버가 초기화 작업의 일환으로 MAC 회로에 설정한 후에만 유효하게 됩니다.
초기화 작업이 끝난 후에는 LAN 어댑터가 IP의 요청을 기다리는 상태가 됩니다.
패킷에 3개의 제어용 데이터를 추가한다.
LAN 드라이버는 IP 담당 부분에서 패킷을 받으면 그것을 LAN 어댑터의 버퍼 메모리에 복사한다.
복사를 마친 후 패킷을 송신하도록 MAC 회로에 명령을 보내면 MAC 회로의 작업이 시작된다.
MAC 회로는 송신 패킷을 버퍼 메모리에서 추출하고 맨 앞에는 프리 앰블과 스타트 프레임 딜리미터라는 두 개의 데이터를 맨 끝에는 FCS(프레임 체크 시퀀스)라는 오류 검출용 데이터를 부과한다.
신호의 전압이나 전류의 값을 읽고 0과 1의 비트값으로 되돌리는데 신호의 변화가 없어지면 비트 구분을 판단할 수 없게 된다. 그래서 이 문제를 사용하기 위해 클록이라는 신호를 보내는 방법을 사용한다.
클록 신호 합성
데이터 신호와 클록 신호가 전달되는 시간에 차이가 생겨 클록이 틀어질 수 있습니다.
이 문제를 해결하기 위해 데이터 신호와 클록 신호를 합성하여 한 개의 신호로 만들 수 있습니다.
프리 앰블
클록 신호의 타이밍을 판단하는 것이 중요하며, 클록이 변화하는 주기는 결정되어 있습니다.
잠시 신호의 변화를 볼 수 있다면 타이밍을 파악할 수 있습니다.
패킷 앞에 클록 신호의 타이밍을 잡기 위한 특별한 신호를 부가하는 것이 프리 앰블의 역할입니다.
스타트 프레임 딜리미터
수신측은 이것을 표기하여 신호에서 데이터를 추출하기 시작합니다.
스타트 프레임 딜리미터는 패킷의 시작을 나타내는 표시가 됩니다.
FCS
데이터가 변한 경우를 검출하기 위해 FCS를 사용합니다.
FCS를 패킷 끝에 부가하여 이를 확인할 수 있습니다.
허브를 향해 패킷을 송신한다.
신호 송신에는 반이중 모드와 전이중 모드 두 가지 방식이 있다. 리피터 허브를 사용한 경우 반이중 모드를 사용하며, 스위칭 허브를 사용한 경우 전이중 모드를 사용한다.
반이중 모드는 신호 충돌 해결 방법
- 케이블에 다른 기기가 송신한 신호가 있는지 확인한다.
- 신호가 흐르고 있다면 종료될 때까지 기다리고, 그 후 송신을 시작한다.
- MAC 회로가 디지털 데이터를 전기 신호로 변환하여 PHY 회로에 보낸다.
- PHY 회로는 이 신호를 케이블에 송출하는 형식으로 변환하여 송신한다.
- 신호 충돌이 발생할 경우, 기기는 송신을 중지하고 재밍 신호를 보낸 후 일정 시간 기다린 후 다시 송신을 시도한다. 기기간 대기 시간이 겹치지 않도록 MAC 주소를 기반으로 한 난수를 이용해 대기 시간을 계산한다.
전이중 모드에서는 송수신을 동시에 실행하며, 충돌이 발생하지 않는다. 따라서 반이중 모드와 같은 복잡한 처리가 필요하지 않으며, 수신 신호선에서 신호가 흘러와도 단순히 신호를 보낸다.
이더넷에서 리피터 허브를 사용한 반이중 동작에서의 수신 동작
1. 모든 기기가 송신한 신호를 수신 신호선에 받아들인다.
2. 프리앰블을 이용해 타이밍을 계산하고, 스타트 프레임 딜리미터 이후의 비트부터 디지털 데이터로 변환한다.
3. PHY 회로에서 신호를 공통 형식으로 변환하여 MAC 회로에 전달한다.
4. MAC 회로에서 신호를 디지털 데이터로 변환하여 버퍼 메모리에 저장한다.
5. 패킷의 FCS 값을 계산하고, 정상 패킷인지 확인한다.
6. 수신처 MAC 주소를 확인하고, 자신의 MAC 주소와 일치하는 경우 패킷을 받아 저장한다.
7. 패킷 수신 완료 시 인터럽트를 발생시켜 통지한다.
8. 이 과정을 통해 이더넷에서 리피터 허브를 사용한 반이중 동작에서 수신 동작이 처리되며, 패킷을 정상적으로 받아 저장하게 된다.
인터럽트 과정
1. LAN 어댑터가 확장 버스 슬롯 부분에 있는 인터럽트용 신호선에 신호를 보냅니다. 이 신호선은 컴퓨터 본체측의 인터럽트 컨트롤러를 통해 CPU와 연결되어 있습니다.
2. 신호가 흘러오면, CPU는 실행하던 작업을 보류하고 OS 내부의 인터럽트 처리용 프로그램으로 전환합니다. 이때 LAN 드라이버가 호출되어 LAN 어댑터를 제어하며 송수신 동작을 실행합니다.
3. 인터럽트에는 번호가 할당되어 있어서 LAN 어댑터를 설치할 때 번호를 하드웨어로 설정합니다.
4. 인터럽트 처리용 프로그램은 하드웨어 인터럽트 번호에 대응하도록 드라이버 소프트웨어를 등록합니다. 예를 들어, LAN 어댑터에 11번 인터럽트 번호를 설정하면, 인터럽트 처리용 프로그램에 등록하여 LAN 어댑터가 인터럽트를 걸면 LAN 드라이버가 호출됩니다. 현재는 PnP (자동 설정 기능) 사양에 따라 번호를 자동으로 설정하므로 인터럽트 번호를 걱정할 필요가 없습니다.
5. 인터럽트에 의해 LAN 드라이버가 동작하고, LAN 어댑터의 버퍼 메모리에서 수신한 패킷을 추출합니다.
6. LAN 드라이버는 MAC 헤더의 타입 필드 값으로부터 프로토콜을 판별합니다.
7. LAN 드라이버는 타입 필드의 값에 대응하는 프로토콜 스택에 패킷을 전달합니다.
8. 프로토콜 스택은 어느 애플리케이션에 대응하는 패킷인지 판단하여 조치를 취합니다.
서버에 응답 패킷을 IP에서 TCP로 넘긴다.
1. LAN 드라이버는 TCP/IP 프로토콜 스택에 패킷을 전달합니다.
2. IP 담당 부분은 IP 헤더 부분부터 검사하여 패킷에 문제가 없는지 확인하고, 수신처 IP 주소를 확인합니다.
- 패킷의 수신처 IP 주소가 LAN 어댑터에 할당된 주소와 일치하면 패킷을 수신합니다.
- 만약 수신처 IP 주소와 자신의 주소가 다르다면, 오류가 발생한 것으로 판단하여 IP 담당 부분이 ICMP 메시지를 사용하여 통신 상대에게 오류를 통지합니다.
3.. 수신처 IP 주소가 올바르면 패킷을 수신합니다.
4. IP 프로토콜에는 조각 나누기 기능이 있어, IP 헤더의 플래그 항목을 통해 패킷이 분할되었는지 확인할 수 있습니다. 분할된 패킷일 경우, IP 담당 부분 내부의 메모리에 일시적으로 보관합니다.
5. 프래그먼트 오프셋 항목에는 패킷이 원래 어느 위치에 있었는지 나타내는 정보가 포함되어 있습니다. 이 정보를 바탕으로 분할된 패킷이 모두 도착하면, 패킷을 원래의 모습으로 되돌리는 리어셈블링 과정을 진행합니다.
6. 리어셈블링이 완료되면, 패킷을 TCP 담당 부분에 전달합니다.
7. TCP 담당 부분은 IP 헤더에 기록된 수신처 IP 주소, 송신처 IP 주소, TCP 헤더에 기록된 수신처 포트 번호 및 송신처 포트 번호의 4가지 항목을 조사하여 해당 소켓을 찾습니다.
8. 소켓을 찾으면 진행 상태가 기록되어 있어, 상황에 따라 적절한 동작을 실행합니다.
UDP 프로토콜을 이용한 송수신 동작
수정 송신이 필요 없는 송신은 UDP가 효율적이다.
TCP는 데이터를 확실하면서도 효율적으로 전달하기 위해서이다.
TCP는 데이터를 확실히 전달하려면 도착한 것을 확인하고 오류로 도착하지 않은 패킷만 다시 보내는 기능이 있기 때문에 복잡하다.
데이터를 확실히 전달하려면 도착하지 않은 경우 전부 다시 보내면 된다.
분할된 패킷을 전부 다시 보내는 것은 낭비이다.
데이터를 패킷 한 개에 수용할 수 있으면 데이터를 전부 다시 보낸다 해도 패킷을 한 개만 보내므로 낭비되지 않는다.
그래서 접속하거나 연결을 끊을 때 제어용 패킷을 보낼 필요가 없다.
그리고 무언가 데이터를 보내면 보통은 회신이 돌아오므로 수신 확인 응답 패킷도 필요 없다.
제어용 짧은 데이터
송신
제어 정보를 교환하는데 있어서 UDP를 사용하는 이유는, 대부분 한 개의 패킷으로 처리되기 때문입니다. UDP는 수신 확인이나 윈도우가 없어, 추가적인 제어 정보의 교환 없이도 효율적으로 작동합니다. 또한, 연결이나 접속 끊기 과정이 없습니다. 송신 데이터가 도착하면, UDP 헤더를 추가하고 IP를 통해 송신하게 됩니다.
수신
IP 헤더에 기록된 수신처 IP 주소, 송신처 IP 주소, UDP 헤더에 기록된 수신처 포트 번호 및 송신처 포트 번호와 같은 네 가지 항목을 참조하여 소켓의 정보와 결합합니다. 이를 통해 데이터를 전달할 애플리케이션을 결정하고 데이터를 전달합니다. 패킷이 오류로 인해 손실되더라도 알지 못합니다.
UDP는 TCP와 달리 보낸 패킷의 상태를 감시하지 않기 때문에, 오류가 발생해도 프로토콜 스택이 신경 쓰지 않습니다. 오류가 발생하면 회답이 되돌아오지 않아, 애플리케이션은 이를 인지하고 필요한 경우 데이터를 다시 보내게 됩니다.
음성 및 동영상 데이터
음성이나 동영상 데이터는 오류를 검출하여 다시 보내도 재생 타이밍이 맞지 않으면 되돌릴 수 없기 때문에 쓸모가 없고 다소 치명적인 문제가 되지 않는 성질이 있다.
그래서 단순히 UDP로 데이터를 보내는 쪽이 더 효율적이다.
