브라우저에 url을 입력하면 일어나는 일에 대해 자세히 정리된 글을 찾았다! 해당 글을 읽고 요약한 내용을 기록해보자.
1. 브라우저에서 URL을 해석한다 = 브라우저에서 URL을 파싱한다.
URL(Uniform Resource Locator) : 웹에서 정해진 자원의 주소. 각각의 유일한 URL은 유일한 자원을 가리킴
ex) http://www.example.com:80/path/to/myfile.html?key1=value1&key2=value2#SomewhereInTheDocument
- http: 프로토콜(컴퓨터 네트워크에서 데이터를 교환하거나 전송하기 위한 방법들의 집합) -> 하이퍼 텍스트 전송 규약을 사용한다.
- www.example.com : 도메인 이름 -> 어떤 웹 서버가 요구되는지 가리킨다. 직접 IP address를 사용하는 것도 가능하지만 편리성 문제 때문에 웹에서 잘 사용되지는 않는다.
- 80 : 포트 -> 기술적으로 웹서버에서 자원을 접근하기 위해 사용하는 gate를 가리킨다.
웹서버가 자원에 접근하기 위해 표준 HTTP 포트를 사용하게 된다면 보통 생략한다. (HTTP : 80, HTTPS : 443)
- path/to/myfile.html : 웹 서버에서 자원의 경로이다.
- ?key=value1&key2=value2 : 웹 서버에 제공되는 추가 파라미터이다. & 기호로 구분된 키/값으로 짝을 이룬 리스트이다.
- #SomewhereInTheDocument : 일종의 북마크이다. 북마크된 지점에 위치한 내용을 보여주기 위해 브라우저에게 방향을 알려준다. 부분 식별자(fragment identifier)라고 해서 요청이 서버에 보내지지 않는다.
ex) https://bbeeyaks-moment.tistory.com/
- 자원 "/" : 메인 페이지를 가져오기
2. DNS 서버 검색
DNS 서버에서 IP주소를 받아와 도메인 이름을 IP주소로 변환한다. 숫자로 이루어진 IP 주소를 기억하는 것은 어렵기 때문에 DNS(Domain Name System)을 사용한다.
IP : 인터넷 상에서 컴퓨터 간 통신할 수 있도록 하는 주소
DNS Server : IP 주소와 도메인이 저장되어 있는 서버
브라우저는 도메인이 캐시에 들어있는지 확인한다(크롬에서 DNS 캐시를 보려면 chrome://net-internals/#dns 확인 가능). 찾지 못하면 브라우저는 검색을 위해 gethostbyname 라이브러리 함수를 호출한다. gethostbyname은 DNS를 통한 호스트명 확인을 시도하기 전에 호스트명이 로컬의 hosts 파일에서 참조될 수 있는지 확인한다. gethostbyname이 캐시와 hosts 파일 모두에서 호스트명을 찾지 못하면 네트워크 스택에 정의된 DNS 서버에 요청을 보낸다. 일반적으로 로컬 라우터나 인터넷 공급자의 캐시 DNS 서버로 보내진다.
3. 받아온 IP 주소를 가지고 서버 PC에 이동 : ARP 프로토콜
IP 주소를 통해서 해당 IP 서버가 있는 곳이 로컬 네트워크가 아닌 경우에 그 지역 라우터까지 패킷이 전달된다. 그 후 라우터에서 IP 주소에 해당하는 컴퓨터가 누군지 알아내기 위해 MAC 주소가 필요하다. ARP Request를 통해서 MAC 주소를 받아온 후 라우터가 이더넷 패킷을 만들어 전송한다.
- IP : 네트워크 통신에 있어서 통신기기에 할당된 식별번호이다.
이 아이피 주소는 통신기기마다 고유하게 할당되어 있는 것이 아니라 통신사에 일정 금액 지불하고 받아오는 것이기 때문에 경우에 따라 바뀔 수 있다. 상대방 컴퓨터가 내 PC를 찾기 위해 필요한 주소이다.
- MAC : 아이피 주소와 마찬가지로 네트워크 통신에 있어서 통신기기에 할당된 식별번호이다.
MAC 주소는 통신기기 하드웨어 자체에 부여된 고유한 식별번호를 나타내어 세상에 단 하나밖에 없는 유니크한 값을 가지며 변경될 수 없다. 컴퓨터가 서로 통신을 하기 위해 필요하다.
ARP(Address Resolution Protocol)는 주소 결정 프로토콜이며, OSI 7 계층에서 네트워크 계층 주소와 링크 계층 주소 사이의 변환을 담당하는 'IP 프로토콜' 이다. 3 계층인 네트워크 계층에서는 IP 프로토콜을 사용하여 나의 IP에서 상대방 IP로의 경로로 라우터를 거쳐 전송된다. 하지만 실제적으로 우리 컴퓨터는 '랜카드'를 사용하여 네트워크에 연결되어 있기 때문에 3계층에서 2계층으로의 정보 전달을 위해서 MAC 주소가 필요하고, 이를 얻기 위해 ARP 프로토콜이 필요하다.
- 송신자는 목적지 물리주소가 필요하므로 물리 주소 요청을 위한 ARP 요청 패킷을 브로드캐스트로 전송한다. 브로드캐스트를 하는 이유는 목적지 물리주소를 몰라 우선 모두에게 요청하기 위함이다. 요청 패킷에는 송신자 주소가 포함되어 있어서 응답할 수 있다.
- 모든 호스트와 라우터는 송신자가 보낸 ARP 요청 패킷을 수신한다.
- 해당되는 수신자만 자신의 논리주소와 물리주소를 넣어 응답 패킷을 유니캐스트로 전송한다.
네트워크는 통신을 하는 방식에 따라 브로드캐스트, 유니캐스트, 멀티캐스트로 나뉜다.
* 유니캐스트 : 일대일 통신 방법. 데이터를 보내고자 하는 주소(MAC Address)를 프레임에 포함시켜 보내는 방식.
* 브로드캐스트 : 하나의 네트워크 전체에 보내는 통신 방법. 같은 네트워크에 포함된 장비들에게 거부권은 없고 일단 무조건 수신하고 봐야하는 통신법.
4. 데이터를 전송하기 위해 서버와 클라이언트가 TCP 프로토콜을 통해 연결하는 과정 : TCP를 통해 Socket 통신
목적지 서버의 주소를 알고 난 후 데이터를 보낼 때, 소켓을 열고 연결형 통신 프로토콜인 TCP를 이용해서 데이터를 전송한다.
소켓이란 통신을 원하는 프로세스에 할당되는 자원이며, 두 프로그램이 네트워크를 통해 서로 통신할 수 있는 통신 접속점이다. 네트워크 응용 프로그램은 소켓을 통하여 통신망으로 데이터를 송수신한다. 소켓은 응용 프로그램에서 TCP/IP를 이용하는 창구 역할을 하며 응용 프로그램과 소켓 사이의 인터페이스를 '소켓 인터페이스'라고 한다.
소켓을 이용한 네트워크 응용프로그램에서 상대방과 IP 패킷을 주고 받기 위해서는 아래 다섯 정보가 정해져야 한다.
- 통신에 사용할 프로토콜 (TCP(=Stream), UDP(=Datagram Service))
- 자신의 IP 주소
- 자신의 포트번호
- 상대방의 IP 주소
- 상대방의 포트번호
이후 3-way handshake를 통해 TCP Socket 통신이 진행(연결 지향성 소켓의 일반적인 이벤트 흐름)되고, 연결을 해제할 때는 4-way-handshake 를 이용하여 접속을 끊는다.
5. HTTPS인 경우, TLS/SSL handshake 추가
서버는 클라이언트와 연결된 상태에서 HTTP 프로토콜을 통해 클라이언트의 요청을 받아서 응답을 해주기 위한 과정을 거치게 된다. 이때 HTTPS면 SSL 인증서를 통해 서버가 신뢰할 수 있는지 판단하기 위해서 공개키 서명 방식을 사용하는데, 이 방식을 SSL/TLS Handshake 라고 한다.
handshake 과정은 통신을 암호화하는 데 사용할 암호화 알고리즘과 키를 결정하고, 서버를 확인하며 실제 데이터 전송을 시작하기 전에 보안 연결이 이루어 졌는지 확인한다.
- 사용할 프로토콜 버전에 동의
- 암호화 알고리즘 선택
- 디지털 인증서 교환하고 유효성 검사하여 서로 인증
- 비대칭 암호화 기술을 사용하여 공유 비밀키 생성. 그런 다음 SSL 또는 TLS는 공유키를 사용하여 메세지를 대칭 암호화 방식으로 암호화
SSL/TLS Handshake 과정
- 클라이언트는 서버에게 client hello 메시지를 담아 서버로 보낸다. 이때 암호화된 정보를 함께 담는데, 버전, 암호 알고리즘, 압축 방식 등이 함께 담긴다.
- 서버는 클라이언트가 보낸 암호 알고리즘과 압축 방식을 받고, 세션 ID와 CA 공개 인증서를 server hello 메시지와 함께 담아 응답한다. 이 CA 인증서에는 앞으로 통신 이후 사용할 대칭키가 생성되기 전, 클라이언트에서 handshake 과정 속 암호화에 사용할 공개키를 담고 있다.
- 클라이언트 측은 서버에서 보낸 CA 인증서가 유효한 지 CA 목록에서 확인하는 과정을 진행한다.
- CA 인증서에 대한 신뢰성이 확보되었다면, 서버의 공개키를 얻고 난수 바이트를 생성하여 서버의 공개키로 암호화한다. 이 난수 바이트는 대칭키를 정하는데 사용 되고, 앞으로 서로 메시지를 통신할 때 암호화하는데 사용된다. <- 위의 CA 발급 과정에 나온 ~7번
- 만약 2번 단계에서 서버가 클라이언트 인증서를 함께 요구했다면, 클라이언트의 인증서와 클라이언트의 개인키로 암호화된 임의의 바이트 문자열을 함께 보내준다.
- 서버는 클라이언트의 인증서를 확인 후, 난수 바이트를 자신의 개인키로 복호화 후 대칭 마스터 키 생성에 활용한다.
- 클라이언트는 handshake 과정이 완료되었다는 finished 메시지를 서버에 보내면서, 지금까지 보낸 교환 내역들을 해싱 후 그 값을 대칭키로 암호화하여 같이 담아 보내준다.
- 서버도 동일하게 교환 내용들을 해싱한 뒤 클라이언트에서 보내준 값과 일치하는 지 확인한다. 일치하면 서버도 마찬가지로 finished 메시지를 대칭키로 암호화하여 보낸다.
- 클라이언트는 해당 메시지를 대칭키로 복호화하여 서로 통신이 가능한 신뢰받은 사용자란 걸 인지하고, 앞으로 클라이언트와 서버는 해당 대칭키로 암호화된 데이터를 주고받을 수 있게 된다.
6. HTTP 프로토콜로 요청
HTTP 서버가 응답한다.
7. 웹 브라우저에서 표현
- 서버가 리소스(HTML, CSS, JS)를 브라우저에게 제공한다.
- Resource Downloading : 브라우저는 서버로부터 HTML, CSS, JavaScript와 같은 웹사이트에 필요한 리소스를 다운 받는다.
- HTML DOM Tree 구축 : 렌더링 엔진은 전달받은 HTML 문서를 파싱(parsing)해 DOM(Document Object Model, 문서 객체 모델) 트리를 형성한다. 이때, HTML 태그를 노드로 변환하고, 노드간의 계층 관계를 형성한다.
- CSSOM Tree 구축 : 이어서 다운 받은 외부 CSS 파일과 함께 포함된 스타일 요소를 파싱(parsing)해 CSSOM Tree를 형성한다. 이때, CSS 속성을 노드로 변환하고, 노드간의 계층 관계를 형성한다.
- Render Tree 구축 : 만든 DOM 트리와 CSSOM 트리를 결합하여 Render Tree를 구축한다. 이때, 실제 화면에 표시될 요소만을 선택하여 렌더 트리를 형성한다.
- Layout : 각 요소를 어디에 배치할 지 결정한다.
- Paint : 레이아웃 과정이 끝나면 UI 백엔드에서 Render 트리를 화면에 그리기 시작한다.
'CS > 면접을 위한 CS 전공노트' 카테고리의 다른 글
[네트워크] DNS Round Robin 방식의 문제점 (0) | 2023.04.20 |
---|---|
[네트워크] HTTP의 GET과 POST 비교 (0) | 2023.04.20 |
[네트워크] HTTP/HTTPS (0) | 2023.04.19 |
[네트워크] 네트워크 기기/IP 주소 (0) | 2023.04.18 |
[네트워크] 네트워크의 기초/OSI 7계층 & TCP/IP 4계층 (0) | 2023.04.17 |