1. 브라우저의 URL 파싱
1) 어떤 프로토콜을 통해 해당 URL에 요청할 것인지
2) 어떤 URL로 요청할 것인지
3) 어떤 포트로 요청할 것인지
- 명시적으로 포트를 선언하지 않았으면 브라우저에서는 설정된 기본값을 이용해 요청하게 되고 HTTP라면 80 포트를, HTTPS라면 443 포트를 기본 값으로 한다.
2. HSTS 목록 조회
-
HSTS(HTTP Strict transport security)는 HTTP를 허용하지 않고 HTTPS를 사용하는 연결만을 허용하게 하는 기능이다.
-
만약 HTTP로 요청이 왔다면 HTTP 응답 헤더에 "Strict Transport Security" 필드를 포함하여 응답하고 이를 확인한 브라우저는 해당 서버에 요청할 때 HTTPS만을 통해 통신하게 된다.
-
그리고 브라우저의 HSTS캐시에 해당 URL을 저장하는데 이를 HSTS 목록이라고 합니다.
-
이를 통해 브라우저에서는 HSTS 목록 조회를 통해 해당 요청을 HTTPS로 보낼지 판단해 HSTS 목록에 해당 URL이 존재한다면 명시적으로 HTTP를 통해 요청한다 해도 브라우저가 이를 HTTPS로 요청하게 된다.
3. URL을 IP주소로 변환
- www.naver.com 주소, 즉 도메인 네임으로는 컴퓨터끼리 통신할 수가 없기에 이를 인터넷 상에서 컴퓨터가 읽을 수 있는 IP주소로 변환한다.
- 1) 우선 브라우저에서는 자신의 로컬 hosts 파일과 브라우저 캐시에 해당 URL이 존재하는지 확인하고
- 2) 존재하지 않는다면 도메인 주소를 IP주소로 변환해주는 DNS(Domain Name System) 서버에 요청하여 해당 URL을 IP주소로 변환한다.
DNS 서버로 요청하는 과정
- 미리 설정 된 Local DNS에 해당 URL 주소의 IP주소를 요청
Local DNS에 해당 IP주소가 존재한다면 응답하고, 없다면 다른 DNS 서버와 통신하는데 root DNS 서버에 해당 URL의 IP주소를 요청
- root DNS서버도 IP주소가 없다면 하위 DNS 서버에 요청하라고 응답하여 이 응답을 받은 Local DNS는 .com 도메인을 관리하는 DNS 서버에 같은 내용을 요청
- .com DNS 서버에도 IP주소가 없다면 마찬가지로 하위 DNS 서버에 요청하라고 응답하여 이 응답을 받은 Local DNS는 naver.com 도메인을 관리하는 DNS 서버에 같은 내용을 요청
- naver.com DNS 서버에서 IP주소를 응답받은 Local DNS는 해당 IP주소를 캐싱하고 응답
4. 라우터를 통해 해당 서버의 게이트웨이까지 이동
- 요청을 보낼 IP주소를 임시로 10.20.30.6라 가정하면 이 IP주소로 가야 하는 것은 알지만 어떻게 가야 할지 경로는 알 수 없는데 이때 이 요청이 네트워크를 타고 어떻게 이동할지를 네트워크 장비인 라우터의 라우팅을 통해 이루어진다.
- 라우터 내에서 라우팅을 통해 생성한 테이블 포트로 패킷이 포워딩된다.
5. ARP를 통해 IP주소를 MAC주소로 변환
- IP를 통해 특정 LAN에 찾아 올 수 있지만 거기에서 최종 목적 노드로 가기 위해서는 MAC주소가 필요합니다.
- 이를 위해 ARP란 주소 결정 프로토콜(Address Resolution Protocol)로 해당 IP를 그 IP주소에 맞는 물리적인 주소 즉, MAC주소를 찾아냅니다.
- 송신자가 ARP 요청 브로드캐스트를 하면 ARP응답으로 MAC주소를 알려줍니다.
6. 대상 서버와 TCP 소켓 연결
소켓 연결은 3-way-handshake라는 과정을 통해 이루어집니다.
- A클라이언트는 B서버에 접속을 요청하는 SYN 패킷을 보낸다.
- B서버는 SYN요청을 받고 A클라이언트에게 요청을 수락한다는 ACK 와 SYN flag 가 설정된 패킷을 발송하고 A가 다시 ACK으로 응답하기를 기다린다.
- A클라이언트는 B서버에게 ACK을 보내고 이후로부터는 연결이 이루어지고 데이터가 오가게 되는것이다.
HTTP + TLS(SSL) = HTTPS가 등장
HTTPS 는 HTTP 통신을 하되 TLS 프로토콜에 따라 암호화된 통신을 하는 프로토콜로 TLS는 HTTP 방식 뿐만아니라 TCP통신을 하는 FTP같은 프로토콜에도 적용 가능
ALPN
ALPN(Application Layer Protocol Negotiation) TLS handshake 이후에 application layer의 프로토콜과 버전을 결정하기 위한 기능이다.
일례로 HTTP/2에서는 HTTP의 버전을 합의하기 위해서 ALPN을 사용하는데
1> 먼저 client가 자신이 HTTP/1.1과 2를 지원한다는 사실을 ALPN으로 보내면
2> 만약 서버가 ALPN과 HTTP/2를 지원한다면 handhshake 이후 HTTP/2로 통신이 시작되고 ALPN을 지원하지 않으면, ALPN 필드가 없으므로 HTTP/1.1로 통신하게 된다.
SNI
SNI(Server Name Indication)서버명 지정 이라는 뜻으로 client가 요청한 server의 도메인을 - TLS 프로토콜 확장형으로 랜선을 통하여 tcp 통신을 수행할 시에 핸드세이크 과정을 거치게 되는데,
이때 핸드세이크 과정의 시작점에서 웹브라우저에게 호스트명을 정해주고 이 방식을 통하여 동일서버에서 여러개의 SSL 통신이 가능하게 된다.
7. HTTP(HTTPS) 프로토콜로 요청, 응답
-
HTTP의 보안 상 문제, 패킷을 잡아서 보면 클라이언트와 서버가 주고받는 모든 데이터를 볼 수 있기에 HTTP + TLS(SSL) = HTTPS가 등장했습니다.
-
연결이 확정되면 해당 페이지 www.google.com을 달라고 서버에게 요청합니다.
-
서버에서 해당 요청을 받고, 이 요청을 수락할 수 있는지 검사하고 서버는 이 요청에 대한 응답을 생성하여 브라우저에게 전달한다.
8. 브라우저에서 응답을 해석
- 서버에서 응답한 내용은 HTML, CSS, Javascript 등으로 이루어져 있고 이를 브라우저에서 해석, 즉 파싱하여 렌더해준다.