www.naver.com 을 URL에 쳤을 때 일어나는 모든 과정을 아는만큼 소개해주세요.
검색창에 글자를 입력했을 때 키보드로부터 받아오는 과정
// 하드웨어 동작부터 컴퓨터 구조 들어가서 브라우저까지!
# 1. 키를 누를 때 발생하는 이벤트가 브라우저에 전달됨.
- 키보드에 눌렀을 때 해당 키에 할당된 전기회로가 닫히게 됨.
- 닫힌 키의 전기회로는 키보드의 동작 방식에 의해 신호를 키코드 정수로 변환 후 컴퓨터로 전달함.
(키보드 드라이버에서 인터럽트 발생 -> 커널에서 받음 -> 어떤 창이 활성화되어있는지 API 통해서 알아낸 후 주소창의 window 핸들러를 이용해서 전달)
# 2. 전달된 키워드는 포커싱이 된 주소표시줄에 나타남.
- 글자가 입력될 때마다 브라우저는 자체 알고리즘과 시크릿 모드 사용 여부에 따라 자동검색어를 표시함.
- 자동 검색어 알고리즘은 검색 기록이나 즐겨찾기에 기반한다고 함.
입력이 완료된 후 서버로 데이터를 요청하고 받아오는 과정
# 1. 주소창에 원하는 키워드를 입력하면 가장 먼저 URL인지, 검색어인지 확인함.
- URL(Uniform Resource Locator): `http:`, `file:`, `ftp:`, `mailto:`로 시작하는 것을 뜻함.
- 모든 URL은 문자열의 맨 앞에 어떤 프로토콜을 사용하여 액세스하는지 쓰여있음. 즉, 문자열의 맨 앞에 프로토콜이 존재하는 경우 URL로 판단됨.
# 2-1. URL일 경우: 프로토콜, 호스트명(도메인), 포트에 따라 URL 구조를 해석함.
- 어떤 웹 서버에 액세스할지 판명 & 전송할 리퀘스트 메시지를 작성하기 위해 먼저 URL을 해독해야 함.
- `[프로토콜명]//[웹 서버명]/[데이터 출처(파일)의 경로명 (디렉토리명/파일명)]`로 나눠짐.
- 프로토콜을 입력하지 않을 경우, 입력된 값이 도메인이라면 설정된 기본값을 이용해 요청함. (HTTP 프로토콜 사용)
- 도메인 예약어 여부에 따라 판단이 되지 않을까 짐작
- 포트를 입력하지 않을 경우, 설정된 기본값을 이용해 요청함. (HTTP: 80 / HTTPS: 443)
# 2-2. 검색어일 경우: 브라우저의 검색엔진을 이용해 검색 결과를 보여줌.
- 입력받은 문자열을 검색엔진의 URL과 조합해 새로운 URL 형태로 변환함.
- 크롬의 경우, 변환을 위해 검색엔진의 URL 주소를 따로 관리함.
# 3. HTTP 리퀘스트 메시지를 포맷에 따라 작성한 다음, OS에 웹 서버로의 송신을 의뢰함.
- 브라우저는 URL을 해독하거나 HTTP 메시지를 만들지만, 메시지를 네트워크에 송출하는 기능은 없기 때문에 OS에 의뢰해야 함.
- HTTP 리퀘스트 메시지에는 URI(액세스 대상), 동작 메서드(GET, POST 등), 추가 정보가 포함됨.
- 이 때, 도메인이 `HSTS Preload List`에 존재하면 첫 요청을 HTTP가 아닌 HTTPS로 보냄.
- HSTS: 보안 강화 목적, 브라우저가 HTTPS 프로토콜만 사용해서 서버와 통신하도록 강제하는 기능
- HSTS Preload List: HSTS가 적용된 웹 사이트의 명단을 모아둔 리스트 정보
- 웹 사이트에서 HTTPS 적용을 완료하고 HSTS Preload List에 등록할 수 있는 가이드를 준수하면 자동으로 등록됨.
- HSTS Preload List에 등록되면 HTTPS에 문제가 생길 시 서비스 접속이 불가능하며 프로토콜을 다운그레이드 하거나 리스트에서 도메인을 삭제하는 과정이 오래 걸리기 때문에 신중하게 결정해야 함.
- 만약 도메인이 HTTPS만을 지원한다면 301 또는 302 리다이렉트 응답을 통해 HTTPS로 다시 접속하라고 지시함. (Strict-Transport-Security 응답 헤더를 내려줌)
# 4. DNS 서버에 요청하여 해당 도메인을 IP 주소로 변환함.
- DNS(Domain Name System): 웹 사이트의 IP 주소와 도메인 주소를 연결해주는 시스템 (인터넷 전화번호부)
1) 브라우저 -> OS -> Router -> ISP(Internet Service Provider) 순으로 DNS 캐시를 탐색함.
- 네트워크 트래픽을 통제하고 데이터 전송 시간을 줄이기 위해 캐시 저장
2) DNS 캐시에 존재하지 않다면 가장 가까운 DNS 서버로 이동해서 해당 도메인에 맞는 IP를 탐색함.
- 최상위 Root DNS부터 아래로 탐색 => 나누는 기준
3) DNS 서버에서도 존재하지 않으면 주소를 찾을 수 없다는 응답이 돌아옴.
# 5. IP 주소와 일치하는 웹 서버와 TCP 연결을 시도함.
- 일반적으로 TCP/IP 프로토콜을 사용함.
1) 액세스 대상의 IP 주소를 기입하여 데이터를 보내면, 서브넷 안에 있는 허브가 운반하고, 송신측에서 가장 가까운 라우터까지 도착함.
2) 그 다음 라우터가 액세스 대상이 어디에 있는지 판단하고 운반함.
3) 이 중계 동작을 반복하면 최종적으로 액세스 대상에 데이터가 도착함.
- 왜 TCP/IP로 부를까? 이렇게 동작하는 이유는?
- IP -> Mac 주소를 찾기 위해 ARP 사용?
- 스위치, 허브, 라우터의 차이는? 왜 이렇게 나눌까? 브로드캐스팅은 왜 어떻게 동작할까? + 게이트웨이
- 허브가 데이터를 다 뿌리고, 데이터를 받을지 말지는 Mac 쪽에서 판단, 스위치는 응답 받아서 라우터로 연결 => 라우터는 다른 라우터(외부)로 연결
- handshaking
- OSI 7계층
# 6. 웹 서버가 연결을 승낙하면 정상적인 응답 메시지를 클라이언트에 전송함.
- 정상적인 메시지와 오류 발생 케이스는 뭐가 있을까
- 응답을 보내고 연결은 해제됨. 왜? => 비연결성, 비상태성 => 쿠키/세션, 브라우저 저장소 (로컬/세션)
# 7. 응답 받은 데이터를 브라우저에 표시함.
- 패킷이라는 작은 덩어리들로 받아오게 됨. 패킷은 커널 단에서 받기 때문에 브라우저가 받는 건 패킷은 아님. => 그러면 어떻게 해석해서 보여주나?