[10주차] 크롬 주소창에 "www.google.com"을 치면 일어나는 일 (#45)

questions/4-network-web/11.md

@@ -1 +1,191 @@
 # 크롬 주소창에 "www.google.com"을 치면 일어나는 일
+
+## 웹 브라우저에 www.google.com을 입력하고 enter
+
+[10주차] **크롬 주소창에 "[www.google.com"을](http://www.google.xn--com%22-jy1s/) 치면 일어나는 일**
+
+### DNS 서버에 검색하기 전
+
+- 캐싱된 DNS 기록들을 먼저 확인
+1. **브라우저 캐시**
+    - 이전에 www.google.com에 방문했다면, 빠른 재접근 가능
+2. **OS 캐시**
+    - 운영체제 안에 있는 캐시로 `System Call`을 통해 내용에 접근
+3. **라우터 캐시**
+4. **ISP(Internet Service Provider) 캐시**
+    - 통신 회사에서 제공하는 캐시
+
+## DNS(Domain Name Service)로 IP 주소 획득
+
+- ISP 캐시까지 확인 후 , IP주소를 찾을 수 없다면 DNS server에 DNS 쿼리를 보낸다.
+
+### Recursive Search
+
+- ISP의 DNS recursor가 담당
+- 다른 DNS 서버에 google.com의 IP 주소를 아는지 확인한다.
+
+![image](https://github.com/Hoya324/backend-cs-study/assets/96857599/ae1b33dc-3498-4cde-b555-366840300b91)
+
+
+![image](https://github.com/Hoya324/backend-cs-study/assets/96857599/3032aebb-b4ff-46a0-923f-4851c03d8e5c)
+
+
+- DNS recursor에서 Root domain에 쿼리
+- .com DNS인 Top-level domain에 쿼리
+- [google.com](http://google.com) name Server인 Second-level domain에 쿼리
+    - 여기서 www의 ip 주소를 DNS recursor에 보낸다.
+- 이를 통해 IP주소를 얻게 된다.
+
+## 브라우저가 TCP/IP 프로토콜을 사용해 서버에 연결
+
+HTTP 요청: TCP 소켓을 열고 3-way handshake로 연결을 설정
+
+HTTPS 요청: TLS(Transport Layer Security) handshake 과정을 통해 세션키를 생성
+
+### 서버에 3way handshaking을 통해 통신
+
+![image](https://github.com/Hoya324/backend-cs-study/assets/96857599/3f9395a2-a6ed-446f-9491-f90cc6b38a86)
+
+
+- 클라이언트가 SYN 신호를 보내고, 포트를 열어달라 요청한다.
+- 서버가 SYN과 ACK을 보내고, 클라이언트가 보낸 정보가 맞는지 확인 한 후, 서버에 잘 받았다는 ACK을 보낸다.
+
+## 브라우저가 웹 서버에 HTTP request
+
+> 웹 서버 : 정적인 파일(HTML, CSS, 이미지 파일)을 처리
+WAS : 동적인 파일(JS, TS)을 처리
+> 
+- 특정 데이터 요청을 브라우저로부터 받게되면, 웹 서버는 페이지의 로직이나 데이터베이스의 연동을 위해 WAS에게 이들의 처리를 요청한다.
+- WAS는 해당 요청을 통해 동적인 페이지 처리를 담당하고, DB에서 필요한 데이터 정보를 받아 그에 맞는 파일을 생성한다.
+
+### 요청 헤더 구성
+
+**요청, 응답 공통 헤더**
+
+- Date(요청 시각)
+- Content-Length(본문 크기)
+- Content-Type
+- Language(사용자의 언어)
+
+**요청 헤더**
+
+- Host(서버 도메인 이름)
+- User-Agent(사용자 클라이언트 정보)
+- Accept(클라이언트의 허용 파일 형식)
+- Cookie
+- Orgin(Post 같은 요청을 보낼 때, 요청이 어느 주소에서 시작됐는지 나타내는데 이때 보낸 주소와 받는 주소가 다르면 CORS(Cross-Origin Resource Sharing) 문제 발생)
+- If-Modified-Since(페이지가 수정되었다면 최신 버전 페이지 요청을 위한 필드)
+- Authorization(인증 토큰을 서버로 보낼 때 사용하는 헤더)
+
+## 서버가 HTTP response를 보낸다.
+
+### 응답 헤더 구성
+
+- Server(웹서버 정보)
+- Access-Control-Allow-Origin(CORS 에러가 발생하지 않도록 프론트 주소를 적어주는 곳)
+- Allow(가능한 메서드 설정)
+- Content-Disposition(응답 본문을 브라우저가 어떻게 표시할지 알려주는 헤더)
+    - inline: 웹페이지 화면에 표시
+    - attachment: 다운로드
+- Location: 300번대 응답이나 201 Created 응답일 때 어느 페이지로 이동할지 알려주는 헤더
+- Content-Security-Policy(외부 파일을 불러오는 경우, 차단할 소스와 불러올 소스 명시
+
+### 상태코드
+
+- 1xx : 정보가 담긴 메세지
+- 2xx : response 성공
+- 3xx : 클라이언트를 다른 URL로 리다이렉트
+- 4xx : 클라이언트 측에서 에러 발생
+- 5xx : 서버 측에서 에러 발생
+
+## **Critical Rendering Path를 통해 웹 브라우저 화면에 웹 페이지 내용을 출력**
+
+### Critical Rendering Path
+
+- 웹 브라우저에 출력되는 단계
+- 6단계로 분류된다.
+
+![image](https://github.com/Hoya324/backend-cs-study/assets/96857599/8e82e83b-9207-4c37-93ca-8292bf6398a3)
+
+## **DOM 트리 빌드**
+
+- 통신을 통해 받아요 HTML 파일들은 바이트 형태로 전달된다.
+- 바이트 → 문자 → 토큰 → 노드 → 객체 모델로 전환되는 작업이 수행된다.
+
+![image](https://github.com/Hoya324/backend-cs-study/assets/96857599/2ce9e329-031b-49af-bf68-b8cd20e51b33)
+
+
+### 1. 변환 (바이트 -> 문자)
+
+- 바이트 형태의 파일을지정된 인코딩에 따라 개별 문자로 변환한다.
+
+### 2. 토큰화 과정 (문자 -> 토큰)
+
+- "<" 문자를 만나면 상태를 태그 열림으로 변하며,
+
+    이후 만나는 a~z의 문자들을 ">" 문자를 만날때까지
+
+    태크 이름의 상태로 인식하게 된다.
+
+- ">" 문자를 만난 후, 현재 토큰을 발행되고 상태는 다시 자료로 돌아간다.
+- 이후 문자들을 소비하면서 문자 토큰이 생성되고 해당 과정은 "<" 문자를 만날 때까지 진행된다.
+- "<" 문자에 만나면 다시 태크 열림 상태로 변한다..
+
+    "/" 문자는 종료 태그 토큰을 생성하며 태그이름 상태로 변경된다. 해당 상태는 ">" 문자를 만날때까지 유지됩니다.
+
+- 해당 과정을 모든 파일의 자료를 확인할 때까지 반복한다.
+
+### 3. 렉싱 (토큰 -> 노드)
+
+- 생성된 토큰들을 규칙 및 속성에 맞는 객체로 변환시킨다.
+
+### 4. DOM 생성 (노드 -> 객체 모델)
+
+- 생성된 객체는 트리 데이터 구조로 연결이 된다.
+- 해당 트리 데이터 구조는 원래 마크업에서 정의된 상위-하위 관계도 포함이 된다.
+
+해당 프로세스의 최종 출력은 DOM이며, 해당 형태가 트리 형태를 띄고 있기 때문에 `DOM Tree`라고도 부른다.
+
+![image](https://github.com/Hoya324/backend-cs-study/assets/96857599/3d9be5d7-e596-4e17-8cfb-b8996b9aed66)
+
+
+## **CSSOM 트리 빌드**
+
+- HTML에서 사용했던 객체 모델로 전환하는 작업이 CSS 파일에 똑같이 적용된다.
+- CSSOM 트리 형태를 만듬으로써 특정 객체에 최종 스타일을 계산할 때 상위 객체의 스타일을 하향식 규칙을 적용하는 방식으로 계산되는 스타일을 재귀적으로 세분화하게 된다.
+
+![image](https://github.com/Hoya324/backend-cs-study/assets/96857599/27c535f5-260a-4f48-a3b4-d984aa9a5e6e)
+
+
+## **Render Tree 생성**
+
+- 기존에 제작된 DOM과 CSSOM을 결합하여 Render Tree를 생성한다.
+- Render Tree는 렌더링에 필요한 노드만 선택하여 페이지를 렌더링하는데 사용한다.
+
+![image](https://github.com/Hoya324/backend-cs-study/assets/96857599/10fe29e2-4cc7-41ac-a434-7c13d8ef63ca)
+
+
+## **Layout**
+
+- Render Tree의 노드들에 대한 위치와 크기를 계산하는 단계
+
+## **Paint**
+
+- 계산된 값들을 기반으로 화면에 필요한 요소들을 실제로 그리는 작업을 실행
+
+## **Reflow & Repaint**
+
+- reflow:
+    - 특정 액션과 이벤트에 따라 html의 요소의 크기나 위치의 크기를 변경해야 하는 과정
+    - reflow에 따라 다시 페인팅을 해줘야하는 repaint 단계 역시 수행
+
+## **Composition**
+
+- 레아아웃과 페인트를 수행하지 않고 레이어의 합성만 실행시키는 단계
+
+## Reference
+
+- [https://velog.io/@tnehd1998/주소창에-www.google.com을-입력했을-때-일어나는-과정](https://velog.io/@tnehd1998/%EC%A3%BC%EC%86%8C%EC%B0%BD%EC%97%90-www.google.com%EC%9D%84-%EC%9E%85%EB%A0%A5%ED%96%88%EC%9D%84-%EB%95%8C-%EC%9D%BC%EC%96%B4%EB%82%98%EB%8A%94-%EA%B3%BC%EC%A0%95)
+- [https://oizys.tistory.com/36](https://oizys.tistory.com/36)
+- [https://aws.amazon.com/ko/blogs/korea/what-happens-when-you-type-a-url-into-your-browser/](https://aws.amazon.com/ko/blogs/korea/what-happens-when-you-type-a-url-into-your-browser/)
+- [https://inpa.tistory.com/entry/WEB-📚-CORS-💯-정리-해결-방법-👏](https://inpa.tistory.com/entry/WEB-%F0%9F%93%9A-CORS-%F0%9F%92%AF-%EC%A0%95%EB%A6%AC-%ED%95%B4%EA%B2%B0-%EB%B0%A9%EB%B2%95-%F0%9F%91%8F)