김영한님의 모든 개발자를 위한 HTTP 웹 기본 지식 강의를 듣고 정리했습니다.

(1) 인터넷 통신

컴퓨터의 통신

• 인터넷에서 컴퓨터 둘은 어떻게 통신할까? 두 대의 컴퓨터가 바로 옆에 있다면, 케이블을 연결하여 서로 통신할 수 있을 것이다.

• 그런데, 컴퓨터가 물리적으로 멀리 떨어져있다면 케이블로 연결할 수가 없다. 이런 경우 인터넷이 필요하다.

복잡한 인터넷 망

• 인터넷은 단순하지 않다. 노드라고 하는 수많은 중간 서버를 거쳐 메세지가 전달된다.

(2) IP(인터넷 프로토콜)

IP 주소 부여

• 복잡한 인터넷망에서 메세지를 보내려고 할 때 최소한의 규칙이 필요한데, IP 주소가 이를 가능하게 한다. 먼저 클라이언트가 IP 주소를 부여받는다. 서버도 IP 주소가 필요하다.

인터넷 프로토콜의 역할

• 지정한 IP 주소에 데이터 전달
• 패킷(Packet)이라는 통신 단위로 데이터 전달

IP 패킷 정보

• 전송 데이터에 출발지 정보와 목적지 정보를 포함한 것을 패킷이라 한다.

클라이언트 패킷 전달

• 출발지 정보와 목적지 정보를 가진 패킷을 인터넷망에 던진다. 인터넷망의 모든 노드(서버)들은 IP 프로토콜에 의한 규약을 따르고 있다. 따라서 패킷의 출발지와 목적지 정보를 이해한다. 목적지 정보에 맞게 계속해서 패킷을 전달하다보면 최종 목적지까지 패킷이 정확하게 도착할 것이다.

서버 패킷 전달

• 클라이언트로부터 메세지를 전달받은 서버가, 클라이언트로 메세지를 전달하려고 한다. 클라이언트의 패킷을 전달할 때와 마찬가지로 출발지 정보와 목적지 정보를 만들어 패킷을 만들어 전달한다.

IP 프로토콜의 한계

비연결성

• 패킷을 받을 대상이 없거나 서비스 불능 상태여도 패킷을 전송하기 때문에 패킷이 정상적으로 전달된다는 것을 보장하지 않는다.

비신뢰성

• 중간에 패킷이 사라질 가능성이 있다.
• 패킷이 순서대로 도착하지 않을 가능성이 있다.

프로그램 구분

• 같은 IP를 사용하는 서버에서 통신하는 애플리케이션이 둘 이상인 경우, 어떤 데이터인지 구분할 때 어려움이 있다.

대상이 서비스 불능, 패킷 전송

• 클라이언트는 패킷을 받을 대상 서버가 패킷을 받을 상태인지 아닌지 모른다. 따라서 클라이언트는 패킷 보냈고 노드들은 패킷을 열심히 전달했지만, 패킷이 전송되지 않을 수도 있다.

패킷 소실

• 클라이언트에서는 패킷을 정상적으로 보냈지만, 인터넷에서 여러 서버들을 거치면서 패킷이 소실될 수 있다.

패킷 전달 순서 문제 발생

• 전달하려는 메세지가 1500 byte가 넘어가면, 메세지를 끊어서 전송한다. Hello,가 1500 bytde이고 world!가 1500 byte라 가정한다면 클라이언트는 두 개의 패킷을 보낼 것이다. 패킷이 노드를 통과하면서 중간에 서로 다른 경로를 택할 수도 있다. 따라서 최종적으로 world!가 먼저 도착하고 그 이후에 Hello,가 도착할 수 있다.

(3) TCP, UDP

인터넷 프로토콜의 4계층

• 애플리케이션 계층 - HTTP, FTP
• 전송 계층 - TCP, UDP
• 인터넷 계층 - IP
• 네트워크 인터페이스 계층

프로토콜 계층

• 프로그램이 Hello, world! 메세지를 생성한다
• SOCKET 라이브러리를 통해 전달한다.
• TCP 정보를 생성하는데, 메시지 데이터를 포함한다.
• IP 패킷을 생성하는데, TCP 데이터를 포함한다.

패킷

IP 패킷 정보

• 전송 데이터에 출발지 IP와 목적지 IP 정보를 추가한 것을 패킷이라 한다.

TCP/IP 패킷 정보

• IP 패킷 안에 TCP에 관한 정보를 추가한다. 출발지 PORT, 목적지 PORT, 전송 제어, 순서, 검증 정보등을 포함하기 때문에 IP 프로토콜만으로는 해결할 수 없었던 문제들을 해결할 수 있다.

TCP 특징

• 전송 제어 프로토콜(Transmission Control Protocol)
• 연결 지향 - TCP 3 way handshake(가상 연결)
  • 서버와 클라이언트가 연결되었는지 확인 후 메세지를 보낸다.
• 데이터 전달 보증
  • 메세지를 보낸 후 중간에 누락된 경우 이를 알 수 있다.
• 순서 보장
• TCP는 신뢰할 수 있는 프로토콜이며, 현재는 대부분 TCP를 사용한다.

TCP 3 way handshake

• 클라이언트에서 서버로 SYN이라는 메세지를 보내고, 클라이언트의 메세지를 받은 서버는 SYN과 ACK로 응답한다. 클라이언트가 서버의 메세지를 받았다면 다시 ACK를 보내어 연결이 되었음을 인식한다. (SYN : 접속 요청, ACK : 요청 수락)
• 클라이언트와 서버가 서로 메시지를 주고 받으며 연결되었음을 확인하면, 클라이언트에서 서버로 데이터를 전송한다. 참고로 클라이언트가 서버로 확인 메세지를 보내는 3. ACK와 함께 데이터를 전송하는 것도 가능하다.

• 메세지를 3번 주고 받기 때문에 3 way handshake라고 부르며, 이 과정을 통해 클라이언트는 서버를 신뢰할 수 있고 서버도 클라이언트를 신뢰할 수 있다.
• 만약 클라이언트가 SYN 메세지를 보냈지만 서버가 응답하지 않는다면, 클라이언트는 현재 서버에 문제가 있다는 것을 알게된다. 따라서 데이터를 보내지 않을 것이다.
• 3 way handshake는 클라이언트와 서버가 논리적으로 연결된 것을 의미한다. 즉, 전선으로 직접 연결된 물리적인 연결이 아니라는 의미이다. 클라이언트에서 서버까지 도달하는 데 수많은 노드를 지나는데, 각각의 노드들은 클라이언트와 서버가 연결이 되었는지에 대해 관심이 없다.

데이터 전달 보증

• TCP 세그먼트에는 순서 정보가 포함되어 있다. 패킷을 보낸 순서와 패킷을 받은 순서가 다르다면, 서버에서는 잘못 전달된 패킷부터 다시 보내줄 것을 요구한다. 서버의 성능에 따라 자체적으로 패킷의 순서를 최적화할 수도 있다.

UDP 특징

• 사용자 데이터그램 프로토콜(User Datagram Protocol)
• UDP는 기능이 거의 없기 때문에 하얀 도화지에 비유한다.
• 연결을 지향하지도 않고, 데이터 전달을 보증하지도 않고, 순서를 보장하지도 않는다.
• 단순하고 빠르다.
• 정리
  • IP와 거의 같지만, PORT를 포함한다. (체크섬 추가)
  • 애플리케이션에서 추가 작업이 필요하다.
• 그렇다면 UDP를 왜 사용할까? TCP는 3 way handshake를 하는 동안 시간이 오래 걸리고, 다양한 정보들을 포함하기 때문에 데이터의 양이 많고, 데이터의 양이 많다보니 전송 속도를 최적화 하기가 어렵다. 그리고 TCP기반으로 인터넷을 사용하고 있기 때문에 손을 대기가 어렵다. 반면 UDP는 하얀 도화지에 비유할 정도로 기능이 거의 없기 때문에 원하는 기능을 구현하여 다양하게 사용할 수 있다. 따라서 최근에는 속도나 용량을 최적화하기 위해 UDP를 활용하려고 하는 추세이다.

(4) PORT

한 번에 둘 이상을 연결해야 한다면

• 클라이언트가 한 번에 여러 통신을 해야하는 경우가 있다. IP만을 이용하면 어떤 목적의 패킷인지 알 수가 없다. 따라서 애플리케이션 정보를 포함하는 PORT가 필요하다.

TCP/IP 패킷

• IP를 이용하면 목적지 서버를 찾을 수 있고, 서버 안에서의 애플리케이션은 PORT로 구분한다.

PORT

• 같은 IP 내의 프로세스를 구분할 때 PORT를 사용한다.
• 클라이언트가 게임을 하려고 한다면, IP :200.200.200.2 서버에 있는 11220 포트에 연결한다.
• 클라이언트가 웹 브라우저에 요청을 보내고 서버에서 응답을 한다면, IP : 100.100.100.1 서버에 있는 10010 포트로 응답을 한다.

PORT 번호

• 0 ~ 65535 사이에 할당 가능하다.
• 0 ~ 1023은 잘 알려진 포트로, 사용하지 않는 것이 좋다.
  • FTP - 20, 21
  • TELNET - 23
  • HTTP - 80
  • HTTPS - 443

(5) DNS

IP의 한계

• IP는 기억하기 어렵고, IP는 변경될 수 있다.

DNS

• 도메인 네임 시스템(Domain Name System)
• 도메인 명을 IP 주소로 변환하는 전화번호부와 같은 시스템

DNS 사용

• DNS 서버에 도메인명과 IP주소를 등록한다. 클라이언트가 도메인명을 입력하면 DNS 서버가 그에 맞는 IP주소를 알려주고, 그 IP 주소를 가지고 서버에 접속한다.