URL을 입력하면 벌어지는 일
- URL을 웹 브라우저의 주소창에 입력한다.
- 웹 브라우저가 URL을 해석하고, 문법에 맞지 않으면 기본 검색엔진으로 검색한다.
- 문법에 맞으면 URL의 호스트 부분을 인코딩한다.
- HSTS(HTTP Strict Transport Security) 목록을 확인하고 있으면 HTTPS로, 없으면 HTTP로 요청한다.
- DNS(Domain Name Server)조회
- 브라우저/로컬 캐시 확인해서 도메인에 해당하는 IP가 있는지 확인한다.
- 없으면 OS에게 DNS 서버에 요청하라고 지시한다.
- DNS 서버는 해당 도메인에 해당하는 IP를 돌려준다.
- TCP 소켓을 열고 3-way handshake로 연결을 설정한다.
- HTTPS 요청이라면 TLS(Transport Layer Security) handshake 과정을 통해 세션키를 생성한다.
- 세션이 유지되는 동안 서버에게 요청하고 응답을 받는 과정을 반복한다.
- 응답 상태코드에 따라 다르게 처리한다.
- 응답을 디코딩(Decoding)하고 캐싱 가능하다면 캐싱한다.
- 웹 브라우저는 응답받은 HTML/CSS/JS 및 이미지, 폰트 등의 리소스를 사용하여 렌더링 한다.
- 서버와의 세션이 종료되면 4-way handshake로 연결을 종료한다.
HSTS(HTTP Strict Transport Security)
HSTS(HTTP Strict Transport Security)는 간단히 기술하면 Web Site에 접속할 때 강제적으로 HTTPS Protocol로만 접속하게 하는 기능이다.
즉 HTTPS Protocol을 지원하는 Web Site 에서 자신은 HTTPS Protocol만 사용해서 통신할 수 있음을,
접속하고자 하는 Web Browser에게 알려 주는 기능이다.
요약하면 보안을 강화시킬 목적으로 Web Browser에게 HTTPS Protocol만 사용하도록 강제하는 기능이다.
3-way handshake
TCP는 장치들 사이에 논리적인 접속을 성립(establish)하기 위하여 three-way handshake를 사용한다.
TCP 3 Way Handshake는 TCP/IP프로토콜을 이용해서 통신을 하는 응용프로그램이 데이터를 전송하기 전에
먼저 정확한 전송을 보장하기 위해 상대방 컴퓨터와 사전에 세션을 수립하는 과정을 의미한다.
Client > Server : TCP SYN
Server > Client : TCP SYN, ACK
Client > Server : TCP ACK
여기서 SYN은 'synchronize sequence numbers', 그리고 ACK는'acknowledgment' 의 약자이다.
이러한 절차는 TCP 접속을 성공적으로 성립하기 위하여 반드시 필요하다.
TCP의 3-way Handshaking 역할
-
양쪽 모두 데이터를 전송할 준비가 되었다는 것을 보장하고, 실제로 데이터 전달이 시작하기전에 한쪽이 다른 쪽이 준비되었다는 것을 알수 있도록 한다.
-
양쪽 모두 상대편에 대한 초기 순차일련변호를 얻을 수 있도록 한다.
TCP의 3-way Handshaking 과정
[STEP 1]
A클라이언트는 B서버에 접속을 요청하는 SYN 패킷을 보낸다.
이때 A클라이언트는 SYN 을 보내고 SYN/ACK 응답을 기다리는 SYN_SENT 상태, B서버는 Wait for Client 상태이다.
[STEP 2]
B서버는 SYN요청을 받고 A클라이언트에게 요청을 수락한다는 ACK 와 SYN flag 가 설정된 패킷을 발송하고
A가 다시 ACK으로 응답하기를 기다린다. 이때 B서버는 SYN_RECEIVED 상태가 된다.
[STEP 3]
A클라이언트는 B서버에게 ACK을 보내고 이후로부터는 연결이 이루어지고 데이터가 오가게 되는것이다.
이때의 B서버 상태가 ESTABLISHED 이다.
위와 같은 방식으로 통신하는것이 신뢰성 있는 연결을 맺어 준다는 TCP의 3 Way handshake 방식이다.
4-way handshake
3-Way handshake는 TCP의 연결을 초기화 할 때 사용한다면,
4-Way handshake는 세션을 종료하기 위해 수행되는 절차이다.
TCP의 4-way Handshaking 과정
[STEP 1]
클라이언트가 연결을 종료하겠다는 FIN플래그를 전송한다. 이때 A클라이언트는 FIN-WAIT 상태가 된다.
[STEP 2]
B서버는 FIN플래그를 받고, 일단 확인메시지 ACK 보내고 자신의 통신이 끝날때까지 기다리는데 이 상태가
B서버의 CLOSE_WAIT상태다.
[STEP 3]
연결을 종료할 준비가 되면, 연결해지를 위한 준비가 되었음을 알리기 위해 클라이언트에게 FIN플래그를 전송한다. 이때 B서버의 상태는 LAST-ACK이다.
[STEP 4]
클라이언트는 해지준비가 되었다는 ACK를 확인했다는 메시지를 보낸다.
A클라이언트의 상태가 FIN-WAIT ->TIME-WAIT 으로 변경된다.
그런데 만약 "Server에서 FIN을 전송하기 전에 전송한 패킷이 Routing 지연이나 패킷 유실로 인한 재전송 등으로 인해 FIN패킷보다 늦게 도착하는 상황"이 발생한다면 어떻게 될까?
Client에서 세션을 종료시킨 후 뒤늦게 도착하는 패킷이 있다면 이 패킷은 Drop되고 데이터는 유실될 것이다.
A클라이언트는 이러한 현상에 대비하여 Client는 Server로부터 FIN을 수신하더라도 일정시간(디폴트 240초) 동안 세션을 남겨놓고 잉여 패킷을 기다리는 과정을 거치게 되는데 이 과정을 "TIME_WAIT" 라고 한다. 일정시간이 지나면, 세션을 만료하고 연결을 종료시키며, "CLOSE" 상태로 변화한다.
