프로토콜 스택에 메시지 송신을 의뢰한다. - [Ch 01. 웹 브라우저가 메시지를 만든다]

  이전 과정을 통해 IP 주소를 얻었다. 이번 글에서는 데이터의 송신과 수신이 어떻게 동작하는지 알아보고자 한다.

 

📙 1. 데이터 송·수신 동작의 개요

  IP 주소를 이용하여 액세스 대상 웹 서버에 메시지를 송신하기 위해 OS의 내부에 있는 프로토콜 스택에 의뢰한다.

  데이터 송·수신 동작도 DNS 서버에 IP 주소를 조회할 때처럼 Socket 라이브러리에 들어있는 프로그램 부품을 이용하는데, IP 주소를 조회할 때처럼 프로그램 부품을 하나씩 호출하고 끝나는 게 아니라 복수의 부품을 결정된 순번대로 호출한다.

  Socket 라이브러리를 이용한 데이터 송·수신 동작은 위와 같다.

  데이터를 송·수신하는 컴퓨터 사이에 데이터의 통로(파이프) 같은 것이 있고 파이프의 양 끝에 데이터의 출입구인 소켓이 있다.

  그리고 아래와 같이 4가지 과정을 거쳐서 송·수신 동작이 수행된다.

1. 소켓 작성 단계
   클라이언트의 소켓을 만든다.
   (서버 측에서는 소켓을 만들어 놓고 연결을 기다리고 있다.)
2. 접속 단계
   서버 측의 소켓에 파이프를 연결한다.
3. 송·수신 단계
   데이터를 송·수신한다.
4. 연결 끊기 단계
   파이프를 분리하고 소켓을 말소한다.

  이제부터 각 과정을 하나씩 순서대로 살펴보자.

 

 

📙 2. [1단계] 소켓의 작성 단계

  우선, 전체적인 통신 과정은 위와 같다.

 

<디스크림터> = socket(<IPv4 사용>, <스트림형,...);

  소켓을 만들기 위해서 소켓 라이브러리의 socket이라는 프로그램 부품을 호출하면 된다.

  소켓이 생기면 디스크립터라는 것이 돌아오는데, 이것은 하나하나의 소켓에 할당한 번호와 같은 것이다. (복수의 소켓이 한 대의 컴퓨터에 존재할 수 있기 때문에 사용한다.)

 

 

📙 3. [2단계] 파이프를 연결하는 접속 단계

connect(<디스크립터>, <서버의 IP 주소와 포트 번호>,...);

  만든 소켓을 서버 측의 소켓에 접속하기 위해 Socket 라이브러리의 connect라는 프로그램 부품을 호출한다.

  connect를 호출할 때, '디스크립터, 서버의 IP주소, 포트 번호'를 지정한다. 그 이유는 아래와 같다.

1. 디스크립터
   프로토콜 스택이 통지받은 디스크립터를 보고 어느 소켓을 서버 측의 소켓에 연결할지를 판단한다.
2. IP 주소
   액세스 대상 서버의 IP 주소다.
3. 포트 번호
   IP 주소로 지정할 수 있는 것은 네트워크의 어느 컴퓨터인가 하는 것까지다.
   즉, IP 주소로는 소켓을 지정할 수 없다.
   그래서 포트 번호를 이용하여 해당 IP 주소의 소켓을 지정한다.

  그렇다면 한 가지 의문점이 있다. 포트 번호에 대한 정보가 없는데 포트 번호를 몇 번으로 지정해야 하는가에 대한 의문이다.

  그에 대한 답은 '서버 측의 포트 번호는 애플리케이션의 종류에 따라 미리 결정된 값을 사용한다.'이다. 예를 들어 웹은 80번, 메일은 25번을 사용하는 식이다.

 

 

📙 4. [3단계] 메시지를 주고받는 송·수신 단계

write<디스크립터>, <송신 데이터>, <송신 데이터 길이>);

  디스크립터와 송신데이터를 지정하여 write를 호출하면 프로토콜 스택에 송신 데이터를 서버에 전송한다.

  송신 데이터는 네트워크를 통해 전부 그대로 액세스 대상의 서버에 도착한다. 그리고 서버는 수신 동작을 실행하여 받은 데이터의 내용을 조사하고 적절한 처리를 실행하여 응답 메시지를 보낸다.

 

<수신 데이터 길이> = read(<디스크립터), <수신 버퍼>,...);

  응답 메시지가 오면 이번에는 메시지를 수신하는 동작이 실행된다. 수신할 때는 Socket 라이브러리의 read라는 프로그램 부품을 통해 프로토콜 스택에 수신 동작을 의뢰한다.

  수신한 응답 메시지를 수신 버퍼라고 부르는 메모리 영역에 저장한다. 수신 버퍼에 메시지를 저장한 시점에 메시지를 애플리케이션에 건네준다.

 

 

📙 5. [4단계] 연결 끊기 단계

close(<디스크립터>);

  웹에서 사용하는 HTTP 프로토콜에서는 본래 응답 메시지의 송신을 완료했을 때 웹 서버 측에서 연결 끊기 동작을 실행하므로 먼저 웹 서버 측에서 close를 호출하여 연결을 끊는다.

  그러면 이것이 클라이언트 측에 전달되어 클라이언트의 소켓은 연결 끊기 단계로 들어간다.

  그리고 브라우저가 read로 수신 동작을 의뢰했을 때 read는 수신한 데이터를 건네주는 대신 송·수신 동작이 완료되어 연결이 끊겼다는 사실을 브라우저에 통지한다. 이로써 송·수신이 종료되었다는 것을 알 수 있으므로 브라우저에서도 close를 호출하여 연결 끊기 단계에 들어간다.

 

  위에서 살펴본 것처럼 본래는 '접속, 리퀘스트 메시지 송신, 응답 메시지 수신, 연결 끊기'라는 동작을 반복한다.

  그러나 이렇게 계속 반복하는 것은 비효율적이기 때문에 연결을 끊지 않고 요청과 응답을 주고받는 것을 가능하게 하였다.  이 부분은 뒤에서 알아보도록 하자.

 

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