[네트워크] 1. 웹 브라우저가 메시지를 만든다.

 

도서 기반 정리

성공과 실패를 결정하는 1%의 네트워크 원리 | Tsutomu Tone - 교보문고

목차

• HTTP 리퀘스트 메시지를 작성한다.
• 웹 서버의 IP 주소를 DNS 서버에 조회한다.
• 전 세계의 DNS 서버가 연대한다.
• 프롵토콜 스택에 메시지 송신을 의뢰한다.

 

HTTP 리퀘스트 메시지를 작성한다.

---

1. URL 입력

브라우저는

• 웹 서버에 액세스 하는 클라이언트 기능
• 파일을 다운로드, 업로드하는 FTP(File Transfer Protocol) 클라이언트 기능
• 메일 클라이언트 기능

등의 복합적인 클라이언트 소프트웨어다.
따라서 웹 서버에 액세스 할 때는 어떤 데이터에 액세스하면 좋은지 URL 맨 에 명시된 프로토콜에 따라 판단한다.

 

URL(Uniform Resource Locator) 프로토콜 종류

• http:// -> 웹 서버
• file:
• ftp: -> FTP 서버
• mailto:

 

2. 브라우저의 URL 해독

브라우저가 처음 하는 일은 웹 서버에 보내는 request 메시지를 작성하기 위해, URL을 해독하는 것이다.

URL 요소

프로토콜	//	웹 서버 명	/	디렉토리 명	/	...	파일명
데이터 출처에 액세스하는 방법	나중에 이어지는 문자열이 서버 이름임을 나타냄		생략 가능 데이터 출처(파일)의 경로명

 

3. URL에서 파일명을 생략한 경우

ex1)

http://www.wldwlddl59.tistory.com/dir/

• /dir/ 다음에 파일명을 생략할 수 있다.
• 어느파일에 액세스 해야할지 모른다.
• 그래서 파일명을 생략할 때를 대비해 파일명을 미리 서버측에 설정해둔다.

ex2)

http://www.wldwlddl59.tistory.com/

• 끝에 '/'는 루트 디렉토리를 나타낸다.
• 따라서 ex1에서와 같이 미리 지정해둔 파일에 액세스한다.

ex3)

http://www.wldwlddl59.tistory.com

• 이번엔 디렉토리도 생략되었다.
• 경로명이 아무것도 없는 경우엔, 루트 디렉토리 아래에 미리 설정된 파일에 액세스한다.

ex4)

http://www.wldwlddl59.tistory.com/whatisthis

• 'whatisthis'는 파일로 볼 수 있다.
• 그러나 디렉토리인데 '/'를 끝에 생략한 것일 수도 있다.
• 그래서 파일이 있으면 파일명으로, 없으면 디렉토리명으로 본다.

 

4. HTTP의 기본 개념

HTTP 프로토콜

• 인터넷상에서 데이터를 주고 받기 위한 서버/클라이언트 모델을 따르는 프로토콜이다.

1. URL을 해독하고, 웹 서버와 파일명을 판단해 브라우저는 HTTP request 메시지를 만든다.
2. 클라이언트에서 서버를 향해 request 메시지를 보낸다.
3. 리퀘스트 메시지가 웹 서버에 도착하면, 웹 서버는 그 속에 쓰여있는 내용을 해독한다.
4. URI와 메시지를 조사해 '무엇을' + '어떻게 하는지' 판단후 동작한다.
5. 동작의 결과 데이터를 응답 메시지에 저장한다.
6. 응답 메시지를 클라이언트에 반송한다.
7. 클라이언트에 메시지가 도착하고, 브라우저가 메시지의 안에서 데이터를 추출해 화면에 표시한다.

 

리퀘스트 메시지에는 '무엇을 + 어떻게 해서' 하겠다는 내용이 작성되어 있다.

URI (Uniform Resource Identifier)

• '무엇을'에 해당한다.
• 보통 파일 이름이나 CGI 프로그램의 파일명을 쓴다.
• 혹은 http:로 시작하는 URL을 그대로 작성할 수 있다.
• 즉, 다양한 액세스 대상을 쓸 수 있고, 이러한 액세스 대상을 통칭하는 말이다.

메소드

• '어떻게 해서'에 해당한다.
• 웹서버에 어떤 동작을 하고 싶은지를 전달한다.

HTTP의 주요 메소드

메소드	의미
GET	URI로 지정한 정보 도출 ex) 파일의 경우 해당 파일의 내용을 되돌려 보낸다. - 메소드와 URI 만으로 웹 서버가 무엇을 할지 판단 가능하다. - 따라서 메시지 본문에 쓰는 송신 데이터는 없다. - 데이터 길이에 제한이 있다.
POST	클라이언트에서 서버로 데이터를 송신한다. 폼(ex. 텍스트 입력 상자)에 입력한 데이터를 송신하는 경우에 사용한다. - 폼에 입력한 데이터 등을 메시지 본문 부분에 쓴다. - 데이터 길이에 제한이 없다.
PUT	URI로 지정한 서버의 파일을 치환한다. 지정한 파일이 없는 경우 새로 파일을 작성
DELETE	URI로 지정한 서버의 파일을 삭제한다.

 

5. HTTP 리퀘스트 메시지 만들기

브라우저는 URL을 해독하고, 웹 서버와 파일명을 판단하면, 이것을 바탕으로 HTTP 리퀘스트 메시지를 만든다.

• request 메시지에 쓰는 URI는 한 개만으로 결정되어 있다.
• 한 번에 한 개씩만 읽을 수 있다.

Request Message

<메소드><공백><URI><공백><HTTP 버전>
<필드명>:<필드값>
.
.
.
<공백행>
<메시지 본문>

• 첫 번째 행 : request 라인
  • 메소드가 가장 중요하다.
  • 어떤 메소드를 써야할지 판단해야 한다.
  • 이는 브라우저가 리퀘스트 메시지를 보내는 장면에 따라 달라진다.
    ex) 하이퍼링크 클릭, 송신 버튼 클릭, URL 입력 등
• 중간 : 메시지 헤더, 리퀘스트의 부가적인 정보를 나타낸다.
• 메시지 본문 : 클라이언트에서 서버에 송신하는 데이터

 

6. request 메시지를 보내면 응답이 돌아온다.

기본적으로 첫 번째 행을 제외하곤 리퀘스트 메시지와 같다.

Response Message

<HTTP 버전><공백><status code><공백><응답 문구>
<필드명>:<필드값>
.
.
.
<공백 행>
<메시지 본문>

• 첫 번째 행 : status 라인
• 중간 : 메시지 헤더
• 메시지 본문 : 서버에서 클라이언트로 송신하는 데이터
  
  
• status code + 응답 문구 : request의 실행 결과를 나타낸다.
• status code : 숫자, 프로그램의 실행 결과를 알려주는 목적이다.
• 응답 문구 : 문장, 사람에게 실행 결과를 알리는 목적

status code	설명
1xx	처리의 경과 상황 등을 통지
2xx	정상 종료
3xx	무언가 다른 조치가 필요함을 나타낸다.
4xx	클라이언트 측의 오류
5xx	서버 측의 오류

 

웹 서버의 IP 주소를 DNS 서버에 조회한다.

---

1. IP 주소의 기본

• 브라우저는 URL을 해독하거나 HTTP 메시지를 만든다.
• 하지만 메시지를 네트워크에 송출하는 기능이 없어 OS에 의뢰해 액세스 대상의 웹 서버에 송신한다.
• 이 때 OS에 송신을 의뢰할 땐 서버의 도메인 명이 아닌 IP 주소로 메시지를 받을 상대를 지정해야 한다.
• 따라서 URL 안에 쓰인 서버의 도메인명에서 IP 주소를 조사해야 한다.

 

TCP/IP 기본 개념

서브넷이라는 작은 네트워크를 라우터로 접속해 전체 네트워크가 만들어진다.

• 서브넷 : 허브에 몇 대의 PC가 접속된 것을 한 개의 단위로 생각해 서브넷 이라고 한다.

여기에 **동 **번지 형태로 네트워크 주소를 할당한다.

동 -> 서브넷에 할당 -> 네트워크 번호
번지 -> 컴퓨터에 할당 -> 호스트 번호

IP 주소

네트워크 번호와 호스트 번호를 합친 것으로, 네트워크에 존재하는 각 컴퓨터를 식별하기 위해 할당한 값이다.

• 32bit
• 8비트씩 점으로 구분해 10진수로 표기한다.
• 넷마스크 : 네트워크 번호와 호스트 번호를 구분할 수 있게 한다. (p.58 - 59)
  • 모두 0 : 서브넷 자체를 나타낸다.
  • 모두 1 : 서브넷에 있는 기기 전체에 패킷을 보내는 브로드캐스트를 나타낸다.

 

 

액세스 대상의 서버까지 메시지를 운반할 때는, IP 주소에 따라 액세스 대상이 어디 있는지 판단하고 운반한다.

• 송신측이 메시지를 보내면, 서브넷 안에 있는 허브가 운반하고, 송신측에서 가장 가까운 라우터까지 도착한다.
• 라우터가 메시지를 보낸 상대를 확인해 다음 라우터를 판단하고, 거기에 보내도록 지시해 송신 동작을 실행한다.
• 이 동작 반복하면, 최종적으로 상대 데이터가 도착한다.

 

 

 

2. 도메인명과 IP 주소를 구분하여 사용하는 이유

실행 효율을 위해 구분한다.

IP 주소는 32비트, 즉 4바이트를 사용하는데, 도메인 명은 최대 255바이트까지 사용한다.

그만큼 라우터가 부하되어 데이터를 운반하는 동작에 더 많은 시간이 걸려, 네트워크 속도가 느려지게 된다.

고성능 라우터를 사용해도 속도에는 한계가 있다.
한계에 다다르면, 방대한 양의 데이터가 인터넷의 내부에 정체되어 있을 수 있다.

기술에 발전에 따라 라우터의 동작 속도는 향상되었지만, 그만큼 데이터 양도 증가하고 있다.

 

3. Socket 라이브러리가 IP 주소를 찾는 기능을 제공한다.

IP 주소를 조사하는 방법 : 가까운 운 DNS 서버에 조회한다.

• DNS 서버에 조회 메시지를 보내고, 응답 메시지를 받는다.
• 이는 DNS 서버에 대해 클라이언트로 동작한다.
• DNS Resolver (resolver) : DNS 클라이언트
• Name Resolution(이름 확인) : DNS 원리를 사용해 IP 주소를 조사하는 것
• Resolver : name resolution을 실행하는 것
• Socket 라이브러리 : OS에 포함된, 네트워크 기능을 애플리케이션에서 호출하기 위한 라이브러리

 

4. 리졸버를 이용해 DNS 서버를 조회한다.

<애플리케이션 프로그램 이름> (<매개변수>)
{
    <메모리 영역> = gethostbyname("www.wldwlddl59.tistory.com");
    .
    .
    <HTTP 메시지 송신>
    .
    .
}

1. 리졸버를 호출
2. 리졸버가 DNS 서버에 조회 메시지를 보낸다.
3. DNS 서버에서 응답 메시지가 돌아온다.
4. 응답 메시지 속에 IP 주소가 포함되어 있으므로, 리졸버는 이것을 추출해 브라우저가 지정한 메모리 영역에 저장한다.

 

5. 리졸버 내부의 작동

1. 네트워크 애플리케이션(ex. 브라우저)이 리졸버를 호출하면 제어가 리졸버 내부로 넘어간다.
2. 리졸버가 DNS 서버에 문의하기 위한 메시지를 만든다.
3. 메시지를 DNS 서버에 보낸다.
   • 리졸버도 네트워크에 데이터를 송, 수신하는 기능이 없다.
   • 따라서 리졸버 스스로 실행하는 것이 아닌, OS 내부에 포함된 프로토콜 스택을 호출해 실행을 의뢰한다.
4. 조회 메시지가 DNS 서버에 도착하고, DNS 서버는 메시지에 쓰여있는 조회 내용을 조사해 답을 찾는다.
5. 찾는 것이 DNS 서버에 등록되어 있으면, 답을 응답 메시지에 작성해 클라이언트에게 보낸다.
6. 보낸 메시지가 네트워크를 통해 클라이언트에 도착하고, 프로토콜 스택을 경유해 리졸버에게 건네진다.
7. 리졸버는 내용을 해독해, IP 주소를 추출해 지정된 메모리 영역에 저장한다.
8. 리졸버 동작이 끝나고 제어가 애플리케이션에게 돌아간다.

DNS의 IP 주소는 미리 컴퓨터에 설정되어 있다.

 

전 세계의 DNS 서버가 연대한다.

---

1. DNS 서버의 기본 동작

DNS 서버에 보내는 조회 메시지에 포함된 정보

• 이름 : 서버나 메일 배송목적지와 같은 이름
• 클래스 : 현재는 'IN'으로 통일
• 타입 : 이름에 어떤 타입의 정보가 지원되는지를 나타낸다.
  - A : 이름에 IP 주소 지원
  - MX : 이름에 메일 배송 목적지 지원

DNS 서버에는 이 세가지에 대응해 클라이언트에 회답하는 항목을 등록해 두었다.

 

2. 도메인의 계층

인터넷의 막대한 수의 서버를 한 개의 DNS 서버에 등록하는 것은 불가능하다.
조회 메시지를 받은 DNS 서버에 정보가 등록되어 있지 않은 경우가 발생할 수 있다.
따라서, 정보를 분산시켜 다수의 DNS 서버에 등록하고, 다수의 DNS 서버가 연대해 어디에 정보가 등록되어 있는지 찾아내는 구조다.

• 계층화된 도메인 정보를 서버에 등록할 때, 하나의 도메인을 일괄적으로 취급한다.
• 즉, 도메인 한 대의 정보를 분할해 복수의 DNS 서버에 등록하는 것은 불가능하다.

DNS 서버에 등록한 정보에는 모든 도메인명이라는 계층적 구조를 가진 이름이 붙여져 있다.

•  ex) 회사의 사업부, 부, 과와 같은 계층과 같다고 생각해라
• wldwlddl59.tistory.com
• 오른쪽에 위치한 것이 상위의 계층이다.
• com 도메인 아래에 tistory 도메인이 있고, 그 안에 wldwlddl59라는 이름이 있다.

 

3. 담당 DNS 서버를 찾아 IP 주소를 가져온다.

액세스 대상의 웹 서버가 어느 DNS 서버에 등록되어 있는지 찾아내는 방법이다.

• 하위 도메인을 담당하는 DNS 서버의 IP 주소를 그 상위의 DNS 서버에 등록한다.
• 루트 도메인 : 최상위 도메인
• 루트 도메인의 DNS 서버를 인터넷에 존재하는 모든 DNS 서버에 전부 등록한다.
• 어딘가의 DNS 서버를 액세스하면, 루트 도메인을 경유해 도메인의 계층 아래로 찾아가 최종적으로 원하는 DNS 서버에 도착한다.

 

4. DNS 서버는 캐시 기능으로 빠르게 회답할 수 있다.

현실에선 상위와 하위 도메인을 같은 DNS 서버에 등록하는 경우도 있다.
따라서 루트 도메인에서 차례대로 따라간다는 원칙대로 움직이지 않을 수 있다.

DNS 서버는 한 번 조사한 이름을 캐시에 기록할 수 있다.
조회하는 정보가 캐시에 있으면, 그 정보를 회답한다.

• 조회한 이름이 등록되어 있지 않은 경우, 이름이 존재하지 않다는 것도 캐시에 저장 가능하다.

그러나, 정보가 변경되는 경우도 있으므로, 캐시 안에 저장된 정보가 올바르다 단언할 수 없다.
따라서, 유효 기한을 설정하고, 이 기간이 지나면 캐시에서 삭제한다.
또 조회에 회답시 정보가 캐시에 저장된 것인지의 여부를 알린다.

 

프로토콜 스택에 메시지 송신을 의뢰한다.

---

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

프로토콜 스택

액세스 대상 웹 서버에 메시지를 송신한다. 

• 브라우저 등의 애플리케이션은 자체에서 파이프를 연결하지 않고, 프로토콜 스택에 의뢰한다.
• Socket 라이브러리를 이용한다.
• 아래 그림처럼 송, 수신 컴퓨터 사이에 데이터 통로 같은 것이 있다.
  이것을 통해 데이터가 흐르면서 상대측에 도착한다.
• 실제 파이프가 있는 것은 아니고, 이와 같은 이미지다.
• 파이프는 양방향으로 데이터를 흘릴 수 있다.

데이터 송, 수신 동작

1. 소켓을 만든다.
2. 서버 측의 소켓에 파이프를 연결한다.
   • 서버측에서 먼저 소켓을 만들고, 클라이언트가 파이프를 연결하기를 기다린다.
3. 데이터를 송, 수신 한다.
4. 파이프를 분리하고 소켓을 말소한다.
   • 파이프를 분리할 때는 어디가 먼저 분리되든 상관 없다.

 

2. 소켓의 작성 단계

클라이언트와 서버의 메시지 송 수신 동작

<메모리 영역> = gethostbyname("wldwlddl59.tistory.com");

<디스크립터> = socket(...);

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

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

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

close(<디스크립터>);

• 소켓 라이브러리의 socket이란 프로그램 부품을 호출한다.
• 리졸버와 같이 소켓 내부에 제어가 넘어가서 소켓 만드는 동작을 실행하고, 끝나면 제어가 돌아온다.

 

디스크립터

소켓을 식별하기 위해 사용된다.

• 컴퓨터 내부에선 데이터 송, 수신 동작이 동시에 여러개 진행될수 있다.
• 이 때 소켓을 식별할 때 사용된다.

 

3. 파이프를 연결하는 접속 단계

소켓을 서버측 소켓에 접속하도록 프로토콜 스택에 의뢰한다.

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

디스크립터

• 소켓 만들 때 돌아온 디스크립터다.
• connect가 프로토콜 스택에 디스크립터를 통지한다.
• 프로토콜 스택이 통지 받은 디스크립터를 보고, 어느 소켓을 서버측의 소켓에 접속할지 판단해 접속 동작을 실행한다.
• 컴퓨터 한 대의 내부에서 소켓을 식별하기 위해 사용한다. 따라서 클라이언트가 서버측 소켓의 번호를 알 수 없다.
  이를 알기 위해 IP 주소와 포트번호를 사용한다.

IP 주소

• IP 주소로 지정할 수 있는 것은, 네트워크의 어느 컴퓨터인지 까지다.
• 소켓까지 지정할 수는 없다.

포트번호

• 접속 상대측에서 소켓을 식별하기 위해 사용한다.
• 서버측의 포트 번호는 애플리케이션의 종류에 따라 미리 결정된 값을 사용하는 규칙이 있다
• 웹 : 80번
• 메일 : 25번

클라이언트 측의 소켓 번호는 소켓을 만들 때, 프로토콜 스택이 적당한 값을 골라 할당한다.
그리고 이 값을 프로토콜 스택이 접속 동작을 실행할 때 서버측에 통지한다.

 

4. 메시지를 주고받는 송, 수신 단계

송신 단계

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

1. 송신 데이터를 메모리에 준비한다. HTTP 리퀘스트 메시지가 송신 데이터다.
2. write를 호출할 때 디스크립터와 송신데이터를 지정한다.
3. 프로토콜 스택이 송신 데이터를 서버에게 송신한다.
4. 송신데이터가 네트워크를 통해 액세스 대상 서버에게 도착한다.
5. 서버는 수신 동작을 실행해, 받은 데이터 내용을 조사하고 적절한 처리를 실행해 응답 메시지를 반송한다.

수신 단계

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

1. read라는 프로그램 부품을 통해 프로토콜 스택에 수신 동작을 의뢰한다.
2. 응답 메시지가 돌아올 때 read가 받아서 수신 버퍼에 저장한다.
   • 수신 버퍼 : 수신한 응답 메시지를 저장하기 위한 메모리 영역

 

5. 연결 끊기 단계에서 송, 수신이 종료된다.

브라우저가 데이터 수신을 완료하면, 송수신 동작이 끝난다.
close 라는 프로그램 부품을 통해 소켓 사이를 연결한 파이프와 같은 것이 분리되고, 소켓도 말소시킨다.

close(<디스크립터>);