웹이나 HTTP는 인터넷 네트워크 망에 기반에서 동작하기 때문에, HTTP를 학습하기 전 기초적인 지식을 알아두는 섹션!
1. 인터넷 통신
인터넷에서 컴퓨터 둘은 어떻게 통신할까?
클라이언트(요청) <-> 인터넷 <-> 서버(응답)
클라이언트가 request message를 전송하면 수많은 노드들을 거쳐 서버에 도착한다. 이후 서버에서 요청을 처리하고 응답을 보내는 과정도 동일하게 진행된다.
인터넷 망에서 message가 도착하는 과정은 IP(인터넷 프로토콜)에 대해 학습해야 한다.
2. IP(인터넷 프로토콜)
IP 주소 부여 & IP의 역할
클라이언트와 서버에 IP 주소가 부여된다. ex. 클라이언트(1.2.3.4), 서버(5.6.7.8)
message를 전송하는 것은 편지를 보내는 것과 같다.
편지 봉투(packet)에 편지(message)를 담고, 봉투에 받는 사람의 주소(destination IP address)와 보내는 사람의 주소(source IP address)를 작성해야 전송할 수 있다.
데이터는 IP packet으로 전송된다. (IP packet = 통신 단위)
IP 패킷 정보
IP packet은 헤더와 데이터 부분으로 나뉜다.
헤더에는 source IP address와 destination IP address, 기타 정보(연결 정보, 유저 기계 정보, 데이터 타입, 데이터 언어 정보, ...) 등이 저장되고, 데이터엔 전송할 message가 저장된다.
클라이언트는 목적 주소로 message를 전송한다.
서버는 클라이언트에게서 message를 잘 받았음을 알리기 위해 클라이언트에게 OK message를 전송한다.
만약 잘 받지 못했다면, 다양한 상태 코드를 담아 message를 보낼 수 있다.
| HTTP response status code | description |
| 1XX | Informational(정보 제공) - 임시 응답 |
| 2XX | Success(성공) - 클라이언트의 요청이 잘 처리됨 |
| 3XX | Redirection(리다이렉션) - 주소가 이동됐음을 알림 |
| 4XX | Client Error(클라이언트 에러) - 없는 페이지 요청 등 |
| 5XX | Server Error(서버 에러) - DB 처리 오류 등 |
이외에도 많은 상태 코드가 있다. ex. 404 Not Found - 요청한 페이지를 찾을 수 없습니다.
인터넷 망은 복잡하기 때문에 클라이언트 message의 경로와 서버의 message 경로는 다를 수 있다.
IP 프로토콜의 한계
a. 비연결성
패킷을 받을 대상이 없거나 서비스 불능 상태여도 패킷을 전송
목적 주소로 message를 전송하고 나면 상대가 잘 받았는지 확인할 수 없다.
따라서, 대상 서버가 패킷을 받을 수 있는 상태인진 모르고 그냥 전송하게 된다.
b. 비신뢰성
중간에 패킷이 사라지거나, 여러 개의 패킷이 순서대로 도착하지 않을 수 있음
인터넷 망을 통해 전송되던 패킷이 인터넷에 문제가 생겨 사라지는 경우가 발생할 수 있다.
물론, 소실되더라도 클라이언트는 알 수 없다.
용량이 큰 패킷을 전송할 땐 MTU(Maximum Transfer Unit)에 맞춰 패킷을 자른다.
이때, #1, #2 순서로 보냈으나 두 패킷의 경로가 다를 수 있기 때문에 내가 의도한 대로 도착하지 않을 수 있다.
c. 프로그램 구분
같은 IP를 사용하는 서버에서 통신하는 애플리케이션이 둘 이상일 때
인터넷으로 게임을 하면서 음악도 듣는 경우, 이 두 애플리케이션을 구분하기 어렵다.
3. TCP, UDP
인터넷 프로토콜 스택의 4계층
| Application Layer | HTTP, FTP |
| Transport Layer | TCP, UDP |
| Network Layer | IP |
| Data Link (Interface) Layer | LAN Driver |
프로토콜 계층
Application Layer은 User Space에 속하고, Transport Layer와 Network Layer은 OS Space에 속한다.
Link Layer은 network interface card에 위치하고, LAN driver나 LAN 장비 등에 위치한다.
- User Space의 process(Application Layer)에서 HTTP message를 만들고, Application Layer와 Transport Layer 사이에 있는 socket을 통해 아래 계층으로 전달(system call)한다.
- Transport Layer에선 전달받은 message를 TCP 정보(Port number)를 붙여 TCP segment로 만들어 아래 계층으로 전달한다.
- Network Layer에선 전달 받은 TCP segment를 IP 정보(IP address)를 붙여 IP packet으로 만들어 아래 계층으로 전달한다.
- 이후 Link Layer에서 전달 받은 IP packet을 Ethernet frame(wired link = ethernet; wireless link = wifi)으로 만들어 LAN card를 통해 인터넷으로 전송한다.
아래 계층에 전달할 때마다 message에 계층마다의 헤더 정보(20-Byte)를 붙이기 때문에 점점 길어지게 된다.
TCP/IP 패킷 정보
위에서 IP packet은 헤더와 데이터 부분으로 나뉜다고 했다.
이 경우에 헤더에는 IP 정보를 담고, 전송 데이터엔 TCP segment가 담겨 있다.
데이터를 자세히 살펴보면 또다시 헤더와 전송 데이터로 나눌 수 있다.
헤더엔 TCP 정보(source port number, destination port number, 순서 정보, 검증 정보 등)가 담겨 있으며, 전송 데이터엔 HTTP message가 담겨 있게 된다.
TCP 특징
전송 제어 프로토콜(Transmission Control Protocol)
신뢰할 수 있는 프로토콜로, 현재 대부분의 애플리케이션들은 TCP를 사용한다.
a. 연결지향 - TCP 3-way handshake (가상 연결)
- 클라이언트에서 connect(연결) 요청(SYN 전송)
- 서버에서 connect 요청을 받았음을 알리고(ACK 전송), 클라이언트에 connect 요청(SYN 전송) -> 클라이언트 연결 확립
- 클라이언트에서 connect 요청을 받았음을 알림(ACK 전송) -> 서버 연결 확립
- 마지막 ACK와 함께 데이터를 전송할 수 있음(HTTP request)
- 서버는 그에 맞는 HTTP response를 전송
- 가상 연결 확립 후 클라이언트와 서버는 데이터를 주고받음 -> 양쪽 모두 전송이 끝나면 연결 해제
- 서버와 클라이언트의 물리적인 연결이 아닌, 논리적인 연결임
b. 데이터 전달 보증
위에 IP 프로토콜의 한계에서 적은 내용을 보면, 클라이언트는 서버에서 데이터를 잘 받았는지 알 수 없다.
이를 해결하기 위해 클라이언트가 데이터를 전송하면, 그 데이터를 받은 서버에서 feedback(ACK)을 보내는 방식을 사용한다.
따라서, 데이터를 보냈음에도 ACK를 받지 못했다면 클라이언트 측에서 중간에 데이터가 소실됐거나 서버 상황이 좋지 않음을 알 수 있으며, 데이터를 재전송할 수 있게 된다.
자세히 살펴보면 클라이언트는 packet에 번호를 붙여 전송하고, 서버는 받은 packet의 번호를 ACK에 붙여 해당 packet을 받았음을 알린다.
자신이 보낸 packet 번호와 받은 ACK의 번호가 다른 경우나 ACK가 corrupt 된 경우 클라이언트는 packet을 재전송한다.
c. 순서 보장
최적화 방식마다 다르지만, 보통은 packet의 순서가 다르게 도착할 경우 꼬인 packet부터 다시 보내달라고 요청한다.
TCP segment 헤더에 packet의 순서 정보가 있기 때문에 순서 오류를 파악할 수 있다.
또는, 서버에서 Receive Buffer에 packet을 모아놓고 모든 packet이 도착하면(순서 상관 X) 알아서 정렬하는 방식도 있다.
이때는 클라이언트에 재전송을 요청할 필요가 없다.
UDP 특징
사용자 데이터그램 프로토콜(User Datagram Protocol)
TCP와 다르게 기능이 거의 없다.
위에 말한 TCP의 특징을 모두 가지고 있지 않다.
IP와 특징이 비슷하며, IP에 port 정보와 checksum(오류 감지) 정도만 추가했다고 보면 된다.
따라서, 애플리케이션에서 추가적인 처리가 필요하다.
위에 [IP 프로토콜의 한계 - 같은 IP 내의 프로그램 구분]에서 생기는 문제를 port number를 통해 해결할 수 있다.
ex. 음악 재생(6654), 인터넷 게임(8901), ...
'이걸 왜 쓰지?'라고 생각할 수 있지만 나름의 장점도 가지고 있다.
데이터 전달 및 순서가 보장되진 않지만, 단순하고 빠르기 때문(연결 X, 내부 데이터 크기가 작음)에 속도가 중요하고, 데이터 소실이 상관없는 경우에 사용한다.
4. PORT
한 번에 둘 이상의 process를 연결해야 한다면?
한 컴퓨터에서 여러 process마다 socket을 열어 각자 다른 컴퓨터와 연결될 수 있다.
이때 컴퓨터로 들어오는 packet들을 구분해 각각에 맞는 application layer 전달해야 한다.
a. PORT - 같은 IP 내에서 process 구분
위에서 TCP segment structure을 보면에 source port number와 destination port number를 담아 전송한다.
같은 IP를 가진 process(socket)가 여러 개 존재하더라도 각각 port number를 다르게 갖기 때문에 맞는 상위 계층으로 전달할 수 있게 된다.
b. 할당 가능한 PORT
0 ~ 65535 범위만큼 port를 할당할 수 있다.
여기서 0 ~ 1023 범위는 잘 알려진 port기 때문에 사용하지 않는 것이 좋다.
ex. FTP(20, 21), TELNET(23), HTTP(80), HTTPS(443)
5. DNS
IP 주소는 사용자가 기억하기 어려우며, 변경될 수 있다.
따라서, 사용자는 IP 주소를 이해하기 쉬운 hostname으로 대체해 사용한다. ex. 5.6.7.8(IP address) = www.example.com(hostname)
도메인 네임 시스템(Domain Name System)
hostname을 IP 주소로 매핑해 테이블처럼 갖고 있으며, 계층 구조를 갖는 분산된 데이터베이스의 형태를 띤다.
클라이언트가 hostname으로 IP 주소를 찾는 과정은 다음과 같다.
- 클라이언트가 www.amazon.com의 IP 주소를 요청한다.
- 클라이언트가 root server에서 .com의 DNS server를 찾는다.
- .com DNS server에서 amazon.com의 DNS server를 찾는다.
- amazon.com DNS server에서 www.amazon.com의 IP 주소를 얻는다.
모든 Network Organizations는 Local Network Server(LNS)를 가진다.
LNS는 host와 DNS의 중간에서 cache 역할을 하며, host가 보낸 DNS query는 우선 LNS에 도착한다.
DNS query의 전달 방식(DNS name resolution)은 아래 2가지가 있다.
host가 요청한 hostname에 해당하는 IP 주소가 LNS에 없다면 query를 root DNS server에 전달해 응답받고 값을 저장해 둔다. (= cache)
DNS 테이블에 담기는 records는 다음과 같은 형태를 띤다.
