그림으로 배우는 HTTP & Network 의 1장을 보고 정리한 글입니다.
웹은 HTTP로 나타낸다
웹 브라우저 주소 입력란에 URL을 입력하면 웹 페이지를 볼 수 있다.
- 브라우저 주소 입력란에 URL을 입력하여 어딘가에 송신
- 어딘가에서 응답이 돌아오면 웹 페이지가 표시
웹 브라우저는 웹 서버로부터 리소스라고 불리는 파일 등의 정보를 통해 웹 페이지를 표시
클라이언트에서 서버까지의 흐름을 결정하고 있는 것은
웹에서 HTTP(HyperText Transfer Protocol)라 불리는 프로토콜이다.
프로토콜의 의미는 약속이다.
즉 웹은 HTTP라는 약속을 사용한 통신으로 이루어져 있다.
HTTP가 등장하게 된 배경
초기 HTTP의 목적을 알아보자.
웹은 지식 공유를 위해 고안되었다
1989년 3월 HTTP가 탄생하였다.
팀 버너스 리 박사가 멀리 떨어진 동료와 지식을 공유하기 위해 시스템을 생각해내었다.
최초로 고안하고 개발한 것은 한 문서에서 다른 문서로 이동할 수 있는
하이퍼텍스트에 의해 상호간에 참조할 수 있는 WWW의 기본 개념이 되는 것이었다.
WWW를 구성하는 기술로 문서 기술 언어로는 SGML을 베이스로한 HTML,
문서 전송 프로토콜로는 HTTP,
문서의 주소를 지정하는 방법으로 URL이 제안되었다.
웹이 성장한 시대
1990년 11월 CERN에서 세계 최초의 웹 서버와 웹 브라우저가 개발되었다.
그로부터 3년 뒤인 1993년에 대한민국 최초의 홈페이지가 개발되었다.
대한민국 최초 홈페이지: http://cair.kaist.ac.kr
1993년 NCSA를 기점으로 넷스케이프, 마이크로소프트 등에서 웹 브라우저를 출시했다.
웹 서버 표준의 하나인 아파치(Apache)와 HTML 2.0이 발행되는 등 웹이 약진하게됨.
1995년부터 마이크로소프트와 넷스케이프의 독자적인 HTML 확장으로 인해 많은 유저들을 곤란하게했다.
진보 안하는 HTTP
HTTP/0.9
HTTP가 등장한 건 1990년이지만 이 당시 HTTP가 정식 서양서가 아니었기에
1.0 이전이라는 의미에서 HTTP/0.9라고 불린다.
HTTP/1.0
HTTP가 정식 사양으로 공개된 1996년 5월, HTTP/1.0으로 RFC1945가 발행되었다.
초기 사양이지만 아직까지 많은 서버 상에서 현역으로 가동되고 있는 프로토콜 사양이다.
HTTP/1.1
1997년 1월에 공개된 HTTP/1.1 버전이 현재 가장 많이 사용되고 있는 버전이다.
그 당시의 사양은 RFC2068이지만 최신 버전은 개정판으로 발행된 RFC2616이다.
+
HTTP/2.0
2015년 공개된 HTTP/1.1의 차기 버전.
SPDY라는 구글의 비표준 개발형 네트워크 프로토콜에 기반한다.
HTTP/1.1의 성능 향상에 초점을 맞춘 프로토콜.
HTTP/3.0
2022년 6월 표준화.
기존에 TCP로 통신하는 것과는 달리 UDP 기반의 QUIC 프로토콜을 사용하여 통신한다.
Zero RTT(Rount Trip Time), 패킷 손실에 대한 빠른 대응, 사용자 IP가 바뀌어도 연결이 유지되는 장점이 있다.
네트워크의 기본 TCP/IP
일반적으로 네트워크는 TCP/IP라는 프로토콜에서 움직이고 있다.
HTTP도 그 중 하나
TCP/IP는 프로토콜의 집합
컴퓨터와 네트워크 기기가 상호간 통신하기 위해서는 서로 같은 방법으로 통신해야한다.
서로 다른 하드웨어와 운영체제 등을 가지고 통신하기 위해서는 규칙이 필요하다.
이러한 규칙을 프로토콜이라고 부른다.
프로토콜에는 TCP, IP, DNS, UDP, SNMP, FTP, HTTP, FDDI, IEEE 등이 있다.
프로토콜에는 케이블 규격과 IP 주소 지정 방법, 떨어진 상대를 찾기 위한 방법과 그곳에 도달하는 순서,
웹을 표시하기 위한 순서 등 여러 가지가 있다.
TCP/IP는 이러한 인터넷과 관련된 프로토콜을 포함하고 있다.
계층으로 관리하는 TCP/IP
TCP/IP는 4계층으로 나뉘어져 있다.
- 애플리케이션 계층
- 트랜스포트 계층
- 네트워크 계층
- 링크 계층
계층화된 이유
인터넷이 하나의 프로토콜로 되어 있다면 어떠한 사양이 변경되었을 때 전체를 바꾸어야 한다.
하지만 계층화되어 있으면 사양이 변경된 해당 계층만 바꾸면 된다.
계층화를 통해 설계를 편하게 할 수 있다.
애플리케이션 층은 애플리케이션 담당하는 부분만 고려하면 되고,
상대가 어디에 있는지, 어떠한 루트로 메시지를 전달하는지, 전달한 메시지가 전달되고 있는지
같은 고려를 하지 않아도 된다.
TCP/IP 각 계층의 역할
애플리케이션 계층
- 유저에게 제공되는 애플리케이션에서 사용하는 통신의 움직임을 결정하고 있다.
- TCP/IP에는 여러 가지의 공통 애플리케이션이 존재한다. (FTP, DNS, HTTP 등)
트랜스포트 계층
- 애플리케이션 계층에 네트워크로 접속되어 있는 2대의 컴퓨터 사이의 데이트 흐름을 제공한다
- 트랜스포트 계층에서는 서로 다른 성질을 가진 TCP와 UDP 두 가지 프로토콜이 있다
네트워크 계층(인터넷 계층)
- 네트워크 상에서 패킷의 이동을 다룬다
- 패킷이란 전송하는 데이터의 최소 단위
- 이 계층에서는 어떠한 절차를 거쳐 상대의 컴퓨터까지 패킷을 보낼지 결정하기도 함
- 인터넷의 경우, 상대 컴퓨터에 도달하는 동안 여러 대의 컴퓨터와 네트워크 기기를 거쳐서 상대방에게 배송된다
- 이러한 여러 가지 선택지 중 하나의 길을 결정하는 것이 네트워크 계층
링크 계층(데이터 계층, 네트워크 인터페이스 계층)
- 네트워크에 접속하는 하드웨어적인 면을 다룬다
- 운영체제가 하드웨어를 제어하기 때문에 디바이스 드라이버와 네트워크 인터페이스 카드(NIC)를 포함
- 케이블과 같이 물리적으로 보이는 부분도 포함
- 하드웨어 측면은 모두 링크 계층의 역할
TCP/IP 통신의 흐름
TCP/IP로 통신을 할 때 계층을 순서대로 거쳐 상대와 통신을 한다.
송신하는 측은 애플리케이션 계층 -> 트랜스포트 계층 -> 네트워크 계층 -> 링크 계층 순서이고,
수신하는 측은 반대인 링크 계층 -> 네트워크 계층 -> 트랜스포트 계층 -> 애플리케이션 계층 순서이다.
HTTP를 예로
송신
- 클라이언트의 애플리케이션 계층 HTTP에서 어느 웹 페이지를 보고 싶다라는 HTTP 요청을 보냄
- 트랜스포트 계층 TCP에서 애플리케이션 계층에서 받은 데이터 HTTP 메시지를 통신하기 쉽게 조각내어 안내 번호와 포트 번호를 붙여 네트워크 계층에 전달
- 네트워크 계층 IP에서 수신지 MAC 주소를 추가하여 링크 계층에 전달
수신
- 링크 계층에서 데이터를 받아 순서대로 애플리케이션 계층까지 전달
- 애플리케이션 계층에 도달하게 되면 클라이언트가 보낸 HTTP 요청 내용을 수신하게 됨
송신 측은 계층을 거칠 때 각 계층마다 필요한 헤더 정보를 추가하고
수신 측은 계층을 거칠 때 반드시 해당 계층마다 사용한 헤더를 삭제한다.
이렇게 정보를 감싸는 것을 캡슐화라고 부른다.
HTTP와 관계가 깊은 프로토콜 IP/TCP/DNS
TCP/IP 중 HTTP와 관계가 깊은IP, TCP, DNS 세 개의 프로토콜에 대해 알아보자.
배송을 담당하는 IP
- IP(Internet Protocol)는 네트워크 계층에 속함
- 인터넷을 활용하는 대부분의 시스템이 IP를 이용하고 있음
- IP와 IP 주소는 다르다
- IP는 프로토콜의 명칭
IP의 역할
- 패킷이라는 통신 단위로 상대방에게 데이터를 전달
- 상대방에게 데이터를 전달하기 위해서는 여러 가지 요소가 필요
- 그 중 IP 주소와 MAC 주소가 중요
- IP 주소는 각 노드에 부여된 주소를 가리키고 MAC 주소는 각 네트워크 카드에 할당된 고유의 주소
- IP 주소는 변경 가능하지만 MAC 주소는 기본적으로 변경할 수 없다
IP 통신은 MAC 주소에 의존하여 통신한다.
통신 상대가 같은 랜선에 있지 않은 경우 MAC 주소를 사용하여 목적지를 찾아간다.
이 때 ARP(Address Resolution Protocol)라는 프로토콜이 사용된다.
ARP는 IP 주소를 바탕으로 MAC 주소를 조사할 수 있다.
신뢰성을 담당하는 TCP
- TCP는 트랜스포트 층에 해당함
- 신뢰성 있는 바이트 스트림 서비스를 제공
- 바이트 스트림 서비스 : 용량이 큰 데이터를 TCP 세그먼트라고 불리는 단위 패킷으로 작게 분해하여 관리하는 것
TCP는 대용량의 데이터를 보내기 쉽게 작게 분해하여 상대에게 보내고,
정확하게 도착했는지 확인하는 역할을 담당하고 있다.
확실하게 데이터를 보내기 위해서 TCP는 Three way hanshaking 방법을 사용한다.
- 패킷을 보내고 보내졌는지 여부를 상대에게 확인함
- SYN과 ACK라는 TCP 플래그를 사용
- 송신측에서 최초 SYN 플래그로 상대에게 접속과 동시에 패킷을 보냄
- 수신측에서 SYN/ACK 플래그로 송신측에 접속과 동시에 패킷을 수신한 사실을 전달
- 마지막으로 송신측이 ACK 플래그를 보내 패킷 교환이 완료됨을 전함
- 이 과정 도중 통신이 끊어지면 TCP가 동시에 같은 순서로 패킷을 재전송
이름 해결을 담당하는 DNS
DNS는 HTTP와 같이 응용 계층 시스템에서 도메인 이름과 IP 주소 이름 확인을 제공한다.
사용자는 IP 주소 대신 이름을 이용하여 상대 컴퓨터를 지정한다.
반대로 컴퓨터는 숫자를 나열하는 방법을 더 선호한다.
이러한 문제를 해결하기 위해 DNS가 있다.
DNS는 도메인명에서 IP 주소를 조사하거나 IP 주소로부터 도메인명을 조사하는 서비스를 제공한다.
URI와 URL
웹 브라우저 등으로 웹 페이지를 표시하기 위해 입력하는 주소가 URL
https://www.google.co.kr -> URL
URI는 리소스 식별자
URI(Uniform Resource Identifiers)
RFC2396에서 각각의 단어가 다음과 같이 정의되어 있다.
Uniform
- 통일된 서식을 결정하는 것
- 여러 가지 종류의 리소스 지정 방법을 같은 맥락에서 구별없이 취급
- 새로운 스키마 도입(http: 와 ftp 등)을 용이하게 함
Resource
- 식별 가능한 모든 것
- 도큐먼트 파일, 이미지, 서비스 등 다른 것과 구별할 수 있는 것은 모두 리소스
- 단일 부분이 아닌 복수 집합도 리소스가 될 수 있음
Identifier
- 식별 가능한 것을 참조하는 오브젝트, 식별자
- URI는 스키마를 나타내는 리소스를 식별하기 위한 식별자 (..?)
- 스키마 : 리소스를 얻기 위한 수단에 이름을 붙이는 방법
URI는 리소스를 식별하기 위해 문자열 전반을 나타내는 반면,
URL은 리소스의 장소(네트워크 상의 위치)를 나타낸다.
URL은 URI의 서브셋이다.
RFC3986에 적힌 URI 예
- ftp://ttp.is.co.za/rfc/rfc1808.txt
- http://www.ietf.org/rfc2396.txt
- ldap://[2001:db8::7]/c=GB?objectClass?one
- mailto:John.Doe@example.com
- news:comp.infosystems.www.servers.unix
- tel:+1-816-555-1212
- telnet://192.0.2.16:80/
- urn:oasis:names:specification:docbook:dtd:xml:4.1.2
URL 포맷
URI는 완전 수식 절대 URI(필요한 정보 전체를 지정) 혹은
완전 수식 절대 URL과 브라우저 중의 기준 URI에서 상대 URL(상대적 위치를 지정)이 있다.
스키마
- 리소스를 얻기 위해 사용하는 프로토콜을 지시하는 역할
- 대소문자는 무시되고 마지막에 콜론이 하나 붙음
- data:, javascript: 같이 데이터와 프로그램을 지정할 수도 있음
자격정보(크리덴셜)
- 서버로부터 리소스를 취득하려면 자격정보가 필요
- 유저명과 패스워드를 지정할 수 있음
서버 주소
- www.google.com과 같은 DNS 이름이나 192.168.0.1과 같은 IPv4 주소, [0:0:0:0:0:0:0:1]과 같은 IPv6 주소를 지정
서버 포트
- 서버의 접속 대상이 되는 네트워크 포트 번호를 지정
- 생략하면 디폴트 포트가 사용됨
계층적 파일 패스
- 특정 리소스를 식별하기 위해 서버 상의 파일 패스를 지정
- unix 디렉토리 지정 방법과 유사함
쿼리 문자열
- 파일 패스로 지정된 리소스에 임의의 파라미터를 넘겨주기 위해 사용
- 옵션으로 사용됨
프래그먼트 식별자
- 취득한 리소스에서 서브 리소스를 가리키기 위해 사용됨
- 옵션으로 사용됨