브라우저에 URL을 입력하고 일어나는 일들

 

-개발자 면접 단골 질문-

웹 브라우저에서 보안을 위해 https://tistory.com 주소를 입력하고 엔터를 눌렀다. 그 때부터 페이지가 열릴 때까지 PC에서 일어나는 네트워크 과정을 설명해주세요.

 

 

출처 : https://wangin9.tistory.com/entry/%EB%B8%8C%EB%9D%BC%EC%9A%B0%EC%A0%80%EC%97%90-url-%EC%9E%85%EB%A0%A5-%ED%9B%84-%EC%9D%BC%EC%96%B4%EB%82%98%EB%8A%94-%EC%9D%BC%EB%93%A4-intro?category=827054

[브라우저에 url 입력 후 일어나는 일들] intro

 

1. 브라우저에서 URL을 해석한다.

= 브라우저에서 URL을 파싱한다.

URL(Uniform Resource Locator) 이란?

URL은 웹에서 정해진 자원의 주소이다. 각각의 유일한 URL은 유일한 자원을 가리킨다.

 

http://www.example.com:80/path/to/myfile.html?key1=value1&key2=value2#SomewhereInTheDocument

를 예로 보자

- http: (프로토콜)

HTTP → 하이퍼 텍스트 전송 규약 사용

- www.example.com  (도메인 이름)

어떤 웹 서버가 요구되는지 가리킨다.

- :80 (포트)

기술적으로 웹서버에서 자원을 접근하기 위해 사용하는 gate를 가리킨다.

웹서버가 자원에 접근하기 위해 표준 HTTP 포트를 사용하게 된다면 보통 생략한다. (HTTP 80, HTTPS 443)

- path/to/myfile.html

웹 서버에서 자원의 경로이다.

- ?key=value1&key2=value2

웹 서버에 제공되는 추가 파라미터이다. & 기호로 구분된 키/값으로 짝을 이룬 리스트이다.

- #SomewhereInTheDocument

일종의 북마크이다. 북마크된 지점에 위치한 내용을 보여주기 위해 브라우저에게 방향을 알려준다.

부분 식별자(fragment identifier)라고 해서 요청이 서버에 보내지지 않는다.

- 자원 "/" : 메인 페이지를 가져오기

 

2. DNS 서버 검색

- DNS 서버에서 IP주소를 받아와 도메인 이름을 IP주소로 변환한다.

http://dev2som.tistory.com → 211.231.99.250

   - IP 주소 : 인터넷 상에서 컴퓨터 간 통신할 수 있도록 하는 주소

   - DNS(Domain Name System) Server : IP주소와 도메인이 저장되어 있는 서버

 

3. ARP 프로토콜

- ARP(Address Resolution Protocol) : 주소 결정 프로토콜

- 목적지 IP 주소와 MAC 주소를 알아야 한다.

- 브로드캐스트를 통해 MAC 주소를 확인한다.

 

4. TCP를 통해 Socket 통신

- Socket?

   - 통신을 원하는 프로세스에 할당되는 자원이며 두 프로그램이 네트워크를 통해 서로 통신할 수 있는 통신 접속점이다.

   - 네트워크 응용 프로그램은 소켓을 통하여 통신망으로 데이터를 송수신한다.

   - 소켓은 응용 프로그램에서 TCP/IP를 이용하는 창구 역할을 하며 응용 프로그램과 소켓 사이의 인터페이스를 '소켓 인터페이스'라고 한다.

- 소켓을 이용한 네트워크 응용프로그램에서 상대방과 IP 패킷을 주고 받기 위해서는 아래 다섯 정보가 정해져야 한다.

1. 통신에 사용할 프로토콜 (TCP(=Stream), UDP(=Datagram Service))
2. 자신의 IP 주소
3. 자신의 포트번호
4. 상대방의 IP 주소
5. 상대방의 포트번호

- 이후 3-way handshake를 통해 TCP Socket 통신이 진행된다. (연결 지향성 소켓의 일반적인 이벤트 흐름)

 

5. HTTPS인 경우, TLS/SSL handshake 추가

https://dev2som.tistory.com/41

HTTP & HTTPS

- SSL 인증서로 서버가 신뢰할 수 있는지 판단하기 위해서 공개키 서명 방식을 사용하는데 이때 방식을 SSL/TLS Handshake 라고 한다.

   - handshake 과정은 통신을 암호화하는 데 사용할 암호화 알고리즘과 키를 결정하고 서버를 확인하며 실제 데이터 전송을 시작하기 전에 보안 연결이 이루어 졌는지 확인한다.

1. 사용할 프로토콜 버전에 동의
2. 암호화 알고리즘 선택
3. 디지털 인증서 교환하고 유효성 검사하여 서로 인증
4. 비대칭 암호화 기술을 사용하여 공유 비밀키 생성. 그런 다음 SSL 또는 TLS는 공유키를 사용하여 메세지를 대칭 암호화 방식으로 암호화

1.     공개키로 암호화 하는 경우

    상대방의 공개키로 데이터를 암호화하고 전달하면 데이터를 전달받은 사람은 자신의 개인키로 데이터 복호화합니다.

2.     개인키로 암호화 하는 경우

     개인키의 소유자가 개인키의 데이터를 암호화하고 공개키와 함께 전달합니다. 이 과정에서 공개키와 데이터를 획득한 사람은 공개키를 이용해서 복호화를 하는 것이죠. 데이터 보호의 목적보다는 공개키가 데이터 제공자의 신원 보장하기 위함입니다.

     암호화된 데이터가 공개키로 복호화된다는 것은 공개키와 쌍을 이루는 개인키에 의하여 암호화되었다는 것을 뜻합니다. 즉 데이터의 제공자의 신원 확인이 보장된다는 뜻이기 때문에 전자서명에 이용합니다.

- TLS 세션이 대칭키로 암호화된 어플리케이션 HTTP 데이터를 전송한다.

SSL/TLS Handshake 과정

1. SSL / TLS 클라이언트 컴퓨터가 자신의 버전, 암호 알고리즘 목록, 그리고 사용 가능한 압축 방식을 "client hello" 메시지에 담아 서버로 보냅니다.

 

2. SSL / TLS 서버는 클라이언트가 제공한 목록에서 서버가 선택한 암호 알고리즘, 선택한 압축 방식과 세션 ID 및 CA(Certificate Authority)가 사인한 서버의 공개 인증서를 "server hello" 메시지에 담아 응답합니다. 이 인증서는 대칭키가 생성되기 전까지 클라이언트가 나머지 handshake 과정을 암호화하는 데에 쓸 공개키를 담고 있습니다.

 

3. SSL / TLS 클라이언트는 서버의 디지털 인증서가 유효한지 신뢰할 수 있는 CA 목록을 통해 확인합니다. 

 

4. 만약 CA를 통해 신뢰성이 확보되면 클라이언트는 의사 난수(pseudo-random) 바이트를 생성해 서버의 공개키로 암호화합니다. 이 난수 바이트는 대칭키를 정하는 데에 사용되며 이 대칭키는 나중에 메시지 데이터를 암호화하는 데 사용됩니다.

 

5. SSL / TLS 서버가 "클라이언트 인증서 요청"을 보낸 경우 클라이언트는 클라이언트의 디지털 인증서 또는 "디지털 인증서 없음 경고" 와 함께 클라이언트의 개인 키로 암호화 된 임의의 바이트 문자열을 보냅니다. 이 경고는 경고일 뿐이지만 일부 구현에서 클라이언트 인증이 필수일 경우 handshake 실패합니다.

 

6. 서버는 클라이언트의 인증서를 확인합니다. 난수 바이트를 자기 개인키로 복호화해 대칭 마스터키 생성에 활용합니다. 

 

7. 클라이언트는 handshake의 클라이언트 부분이 완료되었음을 알리는 Finished 메시지를 서버에 보내면서 지금까지의 교환 내역을 해시한 값을 대칭키로 암호화하여 담습니다.

 

8. 서버는 스스로도 해시를 생성해 클라이언트에서 도착한 값과 일치하는지 봅니다. 일치하면 서버도 마찬가지로 대칭키를 통해 암호화한 Finished 메시지를 클라이언트에게 보냅니다.

 

9. 이후부터 SSL / TLS 세션 동안 서버와 클라이언트는 대칭키로 암호화된 어플리케이션(HTTP) 데이터를 주고 받을 수 있습니다.

 

6. HTTP 프로토콜로 요청

HTTP 서버가 응답한다.

 

7. 웹 브라우저에서 표현

- 서버가 리소스(HTML, CSS, JS)를 브라우저에게 제공한다.

- 브라우저에 표시된다.