거북이-https://velog.io/@violet_evgadn 이전완료

MAC 헤더 ◎ MAC 헤더 IP 헤더를 모두 만들었다면 MAC 헤더를 붙여야 한다. 네트워크에선 엔드노드나 라우터에 존재하는 경로표를 통해 패킷을 수신할 다음 중계 노드(라우터) IP 주소를 찾았다. 그런데 왜 굳이 MAC 헤더라는 새로운 제어 정보가 필요한 것일까? 이전에 말했듯 라우터(혹은 엔드노드의 IP 담당)는 TCP/IP 규칙에 의거하여 패킷이 도착할 다음 중계 노드를 찾는다. 문제는 이더넷에서는 TCP/IP 개념이 통용되지 않기 때문에 TCP/IP 규칙에 따라 찾은 주솟값인 IP 주소를 이디넷에 전달하더라도 이더넷은 이를 파악하지 못하므로 패킷을 목적지까지 운송할 수 없다. 따라서 이더넷의 규칙에 의거하여 다음 중계지에 대한 정보를 줘야 하는데 이더넷 규칙으로 찾은 주솟값이 MAC 주소이며 ..

IP 헤더 ◎ IP 헤더 필드 버전 : IP 프로토콜 버전. 현재는 4를 사용하고 있음 IHL(헤더 길이) : IP 헤더의 길이 ToS(서비스 유형) : 패킷을 운반할 때 우선순위 등을 나타냄 처음에는 사양이 모호하여 최근엔 DiffServ라는 사양으로 필드 사용법을 재정의함 전체 길이 : IP 메시지 전체 길이를 나타냄 ID 정보(Identification) : 패킷을 식별하는 번호로 보통 패킷의 참조 번호가 여기에 기록됨 IP 클라이언트에 의해 분할된 패킷(Fragmentation 된 패킷)은 모두 ID 정보 값이 같음 플래그 : 1비트로 조각나누기(Fragmentation)가 가능한지 나타내고 1비트로 현재 패킷이 나눠진 패킷인지 나타냄 필드는 3비트이지만 2비트만 사용함 DF : 1일 경우 Fra..

패킷 ◎ 패킷 구조 패킷은 크게 "헤더"와 "데이터" 두 부분으로 구성되어 있다. 그리고 "헤더"는 이더넷의 제어 정보인 MAC 헤더, IP의 제어 정보인 IP 헤더 그리고 TCP 헤더로 구성되어 있다. 헤더에는 최종 목적지 및 다음 경유지에 대한 정보가 적혀 있어 헤더에 적힌 제어 정보를 통해 최종 목적지에 가기 위한 경로를 찾을 수 있으며 다음 경유지로 데이터가 송신될 수 있다. TCP 헤더는 프로토콜 스택 안에 존재하는 TCP 담당이 생성하며 IP 헤더와 MAC 헤더는 프로토콜 스택 안에 있는 IP 담당이 생성한다. ◎ 간단히 보는 패킷 송신 과정 먼저 데이터를 송신하는 기기가 패킷을 생성한다. 이후 가장 가까운 중계 장치에 만들었던 패킷 송신한다. 중계 장치에서는 패킷의 헤더 내용을 조사하여 자신..

소켓을 생성한 뒤 소켓사이를 연결하는 커넥션을 만들고 데이터 송/수신을 진행한 뒤 연결을 끊는 과정까지 모두 공부해 보았다. 이제 배울 것은 실제 송/수신되는 데이터인 패킷이 어떻게 만들어지는가와 어떻게 송/수신되는가에 대해 배울 차례이다. 하지만 이를 배우기 전 데이터/송신 과정 정체를 정리해 보고 이전에 말했던 오류 검출 및 회복에 대해 알아본 뒤 패킷에 대해 알아보도록 하자. 그림으로 보는 데이터 송/수신 과정 3-way Handshake - 연결 일단 서버 측에서는 애플리케이션을 동작시키면서 소켓을 미리 만든 뒤 접속 대기 상태로 만든다. 이때 소켓을 "Wait for Client 상태"에 있다고 한다. 이후 Client는 데이터 송/수신을 위하여 소켓을 만든다. 그리고 SYN 비트가 1인 TCP..

연결 끊기 ◎ 커넥션 끊기 데이터 송/수신이 완료되었으니 소켓 사이를 연결하고 있던 커넥션을 끊는 단계로 넘어간다. 데이터 송신을 전부 완료했다고 판단한 측에서 먼저 연결 끊기 단계로 들어간다. 예를 들어 웹의 경우 웹 서버에서 클라이언트에게 응답 메시지를 반송 완료하면 데이터 보내기가 완료된다. 즉, 웹 서버에서 메시지가 모두 송신되었음을 먼저 파악하므로 서버 측이 연결 끊기를 시도한다. (이는 데이터 통신 한 번당 연결 과정을 수행하는 HTTP 1.0일 때 상황이다. HTTP 1.1에서는 Keep-Alive라는 상태가 존재하여 응답 메시지를 반송한 후에도 클라이언트는 계속해서 리퀘스트 메시지를 보낼 수 있으므로 클라이언트 측이 먼저 연결 끊기 단계에 들어갈 수도 있다) 아래 상황에선 웹 서버에서 먼저..

데이터 송신 ◎ write connect를 통해 데이터 송/수신을 위한 통로인 커넥션을 만들었으니 데이터를 실제로 송신해 보자. 애플리케이션은 데이터를 송신하기 위해 "write" 메서드를 호출하여 프로토콜 스택에 송신 데이터를 건네준다. 이 동작에는 몇 가지 특징이 존재한다. 먼저 프로토콜 스택은 데이터의 내용에 대해 큰 신경을 쓰지 않는다. 프로토콜 스택에게 있어 전달받은 메시지는 단순히 입력받은 길이만큼 나열된 Binary Data일 뿐이다. 두 번째로 프로토콜 스택은 데이터를 받자마자 송신하는 것이 아닌 송신용 버퍼 메모리 영역에 잠시 저장시킨다는 것이다. 애플리케이션에서 프로토콜 스택에 송신을 의뢰할 때 데이터의 길이는 애플리케이션의 종류나 데이터를 만드는 방법에 따라 결정된다. 한 번에 모든 ..

서버 접속 ◎ 서버 접속이 필요한 이유 클라이언트 쪽에 소켓을 만들었으니 웹 서버 쪽에 존재하는 소켓과 연결하는 과정이 필요하다. 이는 Socket 라이브러리의 "connect" 함수를 통해 수행할 수 있다. 그런데 생각해 보자. 과연 이 연결하는 과정이 왜 필요할까? 이미 클라이언트 PC와 웹 서버가 존재하는 컴퓨터는 케이블로써 연결되어 있는 상태이므로 언제든 통신이 가능한 상태이다. 즉, 물리적으로 이미 통신을 보낼 수 있는 상황에서 왜 소켓을 만들고 소켓끼리 연결하는 과정이 필요할까? 이를 알기 위해선 애플리케이션 프로그램 사이에서 데이티 송/수신을 진행할 때 "프로토콜 스택"을 사용한다는 것을 알아야 한다. 소켓을 만든 직후 애플리케이션에서 데이터 송신을 수행할 경우 프로토콜 스택은 어떤 상황일까..

프로토콜 스택 데이터를 송/수신하는 과정에서 OS에 내장된 프로토콜 스택은 큰 역할을 담당하고 있다. 브라우저가 프로토콜 스택에 송신을 의뢰하면 프로토콜 스택(네트워크용 소프트웨어)과 LAN 어댑터(네트워크용 하드웨어)가 연동하여 네트워크 상에 메시지를 송/수신한다. 그렇다면 TCP/IP 계층 구조가 어떻게 데이 송/수신을 진행하는지 그림으로 알아보자. 위 사진에서 위쪽에 있는 계층이 작업을 의뢰하면 아래쪽에 있는 계층이 그 작업을 수행하는 방식으로 구성되어 있다. 물론 이 상하 관계가 확실하지 않거나 상황에 따라 역전되는 경우도 있으므로 그렇게까지 엄밀히 생각할 필요는 없다. ◎ 네트워크 애플리케이션 가장 위에 있는 계층은 네트워크 애플리케이션으로써 브라우저, 메일러(메일을 쓰는 SW), 웹 서버, 메..

데이터 송/수신 동작 개요 ◎ 개요 이제 브라우저는 Request Message도 만들었고 OS에 메시지 송신을 의뢰하기 위해 IP 주소도 찾아냈다. 남은 것은 브라우저 측에서 OS 내부에 있는 프로토콜 스택에 데이터(Request Message)를 목적지(웹 서버 IP 주소)까지 보내달라고 의뢰하는 단계이다. OS 내부 프로토콜 스택에 메시지 송신을 의뢰할 때에도 이전에 사용했던 "Socket 라이브러리"를 활용한다. 하지만 IP 주소를 조회할 때는 메서드 1개(gethostbyname)만 사용한 것과 반면에 이 단계에선 여러 개의 메서드를 순서대로 사용해야 한다. 즉, OS 내부 프로토콜에 메시지 송신을 의뢰할 때는 라이브러리에 존재하는 복수의 프로그램을 결정된 순번대로 실행시켜야 하기 때문에 훨씬 ..

DNS 서버 기본 동작 ◎ Resolver가 보낸 Request Message DNS 리졸버가 DNS 서버에 보낸 Request Message에는 총 3가지 정보가 포함되어 있다. 이름 서버나 메일 배송 목적지(메일 주소에서 @ 뒷부분의 이름) 같은 이름을 의미한다. 쉽게 생각하면 도메인명을 의미한다고 보면 된다. 클래스 DNS 구조를 고안할 때 인터넷 이외 네트워크에서도 이를 사용할 수 있도록 만들었다. 이 때문에 어떤 네트워크에서 DNS 구조를 사용하는지 식별하기 위하여 클래스라는 정보를 추가했다. 하지만 현재는 인터넷 이외의 네트워크는 소멸되었으므로 클래스는 항상 인터넷을 의미하는 "IN"으로 고정되어 있다. 타입 이름에 어떤 타입의 정보가 지원되는지를 나타낸다. A일 경우 이름에 IP 주소가 지원..