개요
성공과 실패를 결정하는 1% 네트워크 원리를 공부하고 정리한 글이다.
STORY 1 | HTTP 리퀘스트 메시지를 작성한다.
1.1) URL 입력과 해독, HTTP 메시지 주고 받기
URL(Uniform Resource Locator)
URL은 사실 http: 뿐만 아니라 ftp:, file:, mailto:로 시작하는 것 등 여러가지가 있다.
- 보통 우리가 브라우저를 사용할 때는 웹 서버에 접근하는 클라이언트로 사용하지만, 브라우저의 기능은 다양하기 때문이다. 파일을 다운로드/업로드하는 FTP의 클라이언트 기능이나 메일 전송 클라이언트 기능도 가지고 있다.
- 브라우저는 몇 개의 클라이언트 기능을 겸비한 복합적인 클라이언트 소프트웨어다.
각종 URL 형식 예시와 공통점
- 가장 앞부분에서 브라우저에 액세스하는 방법을 나타낸다. ex) http: ftp: news:..
- 맨 앞부분의 액세스하는 방법(프로토콜)에 따라 뒤 형식이 달라진다.
1.2) 브라우저는 먼저 URL을 해독한다.
브라우저는 웹 서버에 보내는 Request Message를 작성하기 위해서 URL을 먼저 해독한다.
→ URL 형식으로부터 어떤 통신인지(프로토콜)를 알 수 있고, 이에 따른 정보들이 존재하기 때문이다.
→ URL 해독을 통해 클라이언트의 접근 위치를 파악한다.
(a) URL의 요소
<http://csstudy.com/network/login.html>
- http: 데이터 출처에 접근하는 방법 즉, 프로토콜
- // : 나중에 이어지는 문자열이 서버의 이름임을 나타냄
- /디렉토리명/+ … +/파일명: 데이터 출처의 경로
- login.html은 파일명으로 생략 가능하다.
http://csstudy.com/network 이런식으로 작성하면 되는데, URL 끝 부분이 /로 끝나는 것은 뒤에 파일이 생략되어 있다는 뜻이다.
파일명을 생략할 때는 미리 서버측에서 ‘index.html’, ‘default.html’ 등과 같은 파일명을 설정해둔다. 젤 뒤의 / 마저 생략하는 경우도 있다. 하지만 이렇게 디렉토리명까지 생략해버리면 무엇을 요청하는지 알기 힘드므로, 지나친 생략일 수 있다. 경로명이 아무것도 없는 경우에는 루트 디렉토리의 아래에 미리 설정된 파일명의 파일로 접근하는 방식으로 인정되고 있다.
1.3) HTTP
URL 해독 후, HTTP 프로토콜을 사용하여 웹 서버에 접근한다.
- 클라이언트는 서버측에 ‘무엇을(URI)’ ‘어떻게(HTTP method)’ 하겠다는 요청을 보낸다.
URI에 나타낸 데이터를 읽고싶다거나, 클라이언트 측에서 입력한 데이터를 URI로 나타낸 프로그램에 전달하고 싶다는 식의 동작이 대표적이다. - 요청을 받은 서버는 그 속에 쓰여있는 내용을 해독한다. 그리고 URI와 메시지를 조사하여 요구에 따라 동작하고, 결과 데이터를 응답 메시지에 저장한다. 응답 메시지의 맨 앞부분에는 실행 결과가 정상 종료인지 이상이 있는지를 나타내는 상태 코드가 있다.
HTTP Request Message
HTTP는 쓰는 방법이 정해져 있으므로, 이에 맞게 브라우저가 Request Message를 제작한다.
- 메소드, URI, HTTP 버전
- 메시지 헤더
- 리퀘스트 메시지에 쓰는 URI는 한 개만으로 결정되어 있으므로 파일을 한 번에 한 개씩만 읽을 수 있기 때문에 파일을 따로따로 읽어야 한다.
- 첫 번째 행에서 주어진 내용보다 더 자세한 정보가 필요한 경우에 2행부터 메시지 헤더를 사용한다.
HTTP Response Message
Request에 대한 결과를 나타낸다.
- 응답 상태 코드와 문구를
- 응답 메시지가 돌아오면 데이터를 추출한 후 화면에 표시한다.
- 서버 측은 단순히 한 개의 리퀘스트에 대해 한 개의 응답만 돌려 보낸다. 필요한 파일을 읽고 레이아웃을 정하여 화면에 표시하는 상태로 전체 동작을 조정하는 것은 결국 브라우저의 역할이다.
STORY 2 | 웹 서버의 IP 주소를 DNS 서버에 조회한다.
2.1) 도메인 - IP 매핑
HTTP 메시지를 만들면 OS에 의뢰하여 웹 서버에게 송신한다.
- 브라우저는 URL을 해독하거나 HTTP 메시지를 만들지만, 직접 전송하고 네트워크에 송출하는 기능은 없다.
- OS에 송신 의뢰를 할 때에는 도메인명이 아니라 IP 주소로 상대를 지정한다. 따라서 HTTP 메시지를 만드는 동작의 다음은 도메인명을 통해 IP 주소를 조사하는 것이 된다.
2.2) IP 주소
TCP/IP 네트워크는 작은 서브넷을 라우터로 연결하여 전체 네트워크를 완성한다. 쉽게 말해서 서브넷은 아파트 주소의 동, 호수는 ip 주소라고 생각하면 된다. 택배 받는 사람 기입란에 접근 대상의 주소를 기입하여 데이터를 보낸다. 그러면 라우터가 받는 사람을 보고 이것이 어떤 호수에 있는지 조사하여 그곳으로 데이터를 중계한다.
- IP는 주소와 같은 것이므로 다른 곳에 같은 값이 할당되면 안 된다. →
- OO동 XX호의 OO동은 서브넷 번호 즉, 네트워크 번호다. XX호는 호스트 번호로, 이 둘을 합쳐서 IP 주소라고 한다.
- IP 주소 = 네트워크 주소 + 호스트 주소
- 송신측이 메시지를 보내면, 서브넷 안에 있는 허브가 데이터를 운반한다.
- 송신측에서 가장 가까운 라우터까지 운반된다.
- 그리고 라우터가 이 메시지 상대를 확인하여 다음 라우터를 판단하고, 거기에 보내도록 지시한다.
- 이후 다시 서브넷의 허브가 라우터까지 메시지를 보낸다.
- 이 동작을 반복하면 최종적으로 상대의 데이터가 도착한다. (TCP/IP의 기본 개념)
IP 주소 표기
(a) IP 주소 본체의 표기 방법
- 10.11.12.13
(b) IP 주소 본체와 같은 방법으로 네트워크를 표기하는 방법
- 10.11.12.13/255.255.255.0(넷마스크)
(b) 네트워크 번호의 비트 수로 넷마스크를 표기하는 방법
- 10.11.12.13/24
(c) 서브넷을 나타내는 주소
- 10.11.12.0/24
- 이 부분이 모두 0이면 서브넷 자체를, 1이면 서브넷 전체에 대한 브로드캐스트를 나타낸다.
- 브로드캐스트 주소 → 네트워크 내의 모든 주소에 데이터를 전달할 때
넷마스크
a.a.a.a처럼 8비트씩 점으로 구분하여 10진수로 표기하는 것이 일반적인 IP 주소다. 이것만으로는 어느 부분이 네트워크 번호인지, 호스트 번호인지 알 수 없다. → IP 주소의 규칙에서는 네트워크 번호와 호스트 번호의 두 가지를 합쳐서 32비트로 한다는 것만 결정되어 있을 뿐, 내역은 결정되어 있지 않다.
- 네트워크를 구축할 때 사용자가 직접 내역을 결정할 수 있다.
- 이 내역을 나타내는 정보를 IP 주소에 덧붙이는데, 이 정보를 넷마스크라고 한다.
- 1으로 표기된 것이 네트워크 번호, 0으로 표기된 것이 호스트 번호
- 1111111 / 111111 / 0000000 / 00000
2.3) 도메인명과 IP 주소를 구분하여 사용하는 이유
■ 사용자가 IP 주소를 일일이 외우는 것에 대한 어려움은 공감이 가는데… 그럼 OS 측에도 도메인명을 알려준 다음, 상대를 지정하고 통신하면 안 될까?
- 실행 효율이라는 관점에서 좋은 방법이 아니다. 인터넷 내부에는 다수의 규칙이 있고, 그것들이 연대하여 데이터를 운반한다.
- IP는 32비트, 즉 4 바이트에 해당하는 개수밖에 없지만, 도메인명은 적어도 수십 바이트부터 최대 255바이트나 있다. 이 문자를 취급하기 위해서 그만큼 라우터가 부하되어 데이터 운반 속도에 직접적인 영향을 미칠 것이다. 도메인 → DNS 서버 …
■ 그렇다면 고성능 라우터를 쓰면 해결되지 않을까?
- 한계가 있다. 한계로 인해 방대한 양의 데이터가 인터넷 내부에 정체되어 있을 수 있다.
- 데이터 양도 기술의 발전에 못지 않은 속도로 증가하고 있다.
⇒ 사람은 이름을 사용하고, 라우터는 IP 주소를 사용한다는 방법이 고안되었고, 현재 이 방법이 정착되어 있다. 이름만 알면 IP 주소를 알 수 있다거나, IP 주소를 알면 이름을 알 수 있다는 원리를 사용하여 양쪽의 차이를 해소하는 것이 DNS의 원리다.
STORY 3 | 전세계의 DNS 서버가 연대한다.
3.1) DNS 리졸버
핵심은 IP 주소를 조사하기 위해 ”DNS에 질의를 한다.”는 것이다. 이를 위해 DNS 서버에 조회 요청을 날리고, 그에 대한 응답 메시지를 받는다. 결국 DNS 서버에 대해 클라이언트로 동작한다. 이 DNS 클라이언트를 DNS 리졸버라고 한다.
- DNS 리졸버(or 단순히 리졸버): 가장 가까운 DNS 서버에 IP 주소를 질의한다. 즉, DNS 서버에 클라이언트로 동작한다.
- 네임 리졸루션(name resolution) : DNS 원리를 사용하여 IP 주소를 조사하는 것
3.2) 소켓 라이브러리와 리졸버
소켓 라이브러리
리졸버는 소켓 라이브러리에 내장되어 있는 기능이다. 소켓 라이브러리는 OS가 네트워크 기능을 할 때 필요한 작업들을 모아놓은 것이다.
브라우저는 URL을 해독하거나 HTTP 메시지를 만들지만, 직접 전송하고 네트워크에 송출하는 기능은 없기 때문에 OS에 이를 의뢰하게 된다. 따라서 위 이미지처럼 애플리케이션 단에서 소켓 라이브러리와 같은 기능을 호출함으로써 송수신을 부탁하게 된다.
3.3) 리졸버 호출과 위치
소켓 라이브러리 내에 구현된 리졸버가 OS에게 실행을 의뢰하고, OS는 이 요청 세미지 대로 송수신을 한다.
세부 내용은 아래와 같다.
3.4) 리졸버 - OS 내부 작동
- 애플리케이션 안에 <메모리 영역> = gethostbyname(”www.cobinding.tistory.com”)과 같이 쓰면 리졸버가 호출되어, DNS 서버에 대한 IP 주소 조회 동작을 실행할 수 있다.
- 브라우저와 같은 애플리케이션이 리졸버(socket 라이브러리)를 호출
- 리졸버가 OS에게 DNS 서버에 조회 메시지를 보내야 한다는 메시지 생성해서 프로토콜 스택 호출
- 프로토콜 스택: OS 내부에 내장된 네트워크 제어용 SW
- OS가 리졸버에게 메시지 받아서 네트워크 영역의 송수신 담당
- LAN 어댑터를 통해서 메시지가 DNS 서버를 향해 송신
- DNS 서버의 응답이 클라이언트에게 위 과정을 거꾸로 거쳐서 반송
- 리졸버는 OS에게 응답 메시지를 받아서, IP 주소를 추출하여 <메모리 영역>에 저장하고 애플리케이션에게 이 IP 주소를 건네줌.
*DNS 서버에 메시지를 송신할 때 IP 주소는 필요 없을까?
→ 컴퓨터에 미리 TCP/IP 설정 하나하나가 되어있다. 리졸버는 여기에서 설정된 DNS 서버의 IP 주소에 조회 메시지를 보낸다!
STORY 4 | 프로토콜 스택에 메시지 송신을 의뢰한다
IP 주소를 조사하고 난 후, 웹 서버에 메시지를 송신하도록 프로토콜 스택에 의뢰한다.
- 프로토콜 스택: 말 그대로 여러 계층이 쌓여있는, 계층 구조로 이루어진 프로토콜을 말한다.
4.1) 프로토콜 스택에 메시지 송신을 의뢰하는 방법
IP 주소를 조회했을 때처럼, Socket 라이브러리의 함수를 사용하되, 결정된 순서대로 호출한다.
- Socket 라이브러리에서는 프로토콜 스택을 호출한다.
- 컴퓨터 사이에는 파이프같은 것을 통해 데이터를 양방향으로 주고 받는다.
두 컴퓨터가 연결되는 순서
- 먼저 서버측에서 소켓(데이터 출입구) 생성
- 소켓에 클라이언트가 연결 요청을 하도록 대기
- 클라이언트에서 소켓(데이터 출입구) 생성, 파이프를 늘려 서버 측의 소켓에 연결 요청 → IP 주소와 포트 번호 등을 가지고 connect 함수 호출
- 양쪽의 소켓이 연결되어 송수신 준비 완료
- 디스크립터: 소켓을 생성할 때 반환되는 정수 값 → 애플리케이션에서 소켓을 식별하기 위해 사용
- IP 주소: 액세스 대상 서버의 ip 주소
- 포트 번호: IP 주소를 통해 어느 컴퓨터인지 알아냈으면,
- 프로토콜 스택: 말 그대로 여러 계층이 쌓여있는, 계층 구조로 이루어진 프로토콜을 말한다.
'CS > Network' 카테고리의 다른 글
[Network] 네트워크 원리 (3) 케이블의 앞은 LAN 기기였다. (1) | 2024.09.03 |
---|---|
[Network] 네트워크 원리(2) - TCP/IP의 데이터를 전기 신호로 만들어 보낸다 (0) | 2024.08.27 |
[Network] 내가 만든 웹 서비스 WireShark로 패킷 분석하기 - 7계층 분석 (0) | 2024.06.23 |
[Network] 내가 만든 웹 서비스 WireShark로 패킷 분석하기 - Spring WebSocket & STOMP (1) | 2024.06.23 |
[Network] Transport Layer, Mux & Demux (0) | 2024.04.24 |