브라우저가 화면을 표시하는 과정2 : Data Fetching

1. Navigation

2. Fetching Data

3. parsing the HTML

4. parsing the CSS

5. executing the Javascript

6. creating the accessibility tree 

7. the Render Tree

단계 중 두 번째입니다.

 

Navigation과정을 통해 서버와 통신할 준비를 마쳤습니다.

이제 본격적으로 Data를 요청하는 순간입니다. 첫 요청은 Markup Document, 바로 HTML파일을 요청하는데, HTTP프로토콜을 이용합니다. HTTP 프로토콜은 HTML과 같은 자원을 가져오기 위한 프로토콜입니다. 이것은 웹에서 모든 데이터 교환의 기반이고 클라이언트-서버 프로토콜입니다. 즉, 자원의 요청은 수신자에 의해 발생하고 이것은 주로 웹 브라우저를 가리킵니다.

HTTP요청은 Method와 URI의 조합으로 이루어집니다. URI는 예를 들면 웹사이트나 이메일 주소 같은 인터넷 자원의 고유 식별자입니다. URI는 5개의 부분으로 이루어집니다. 

1. schema: 사용되는 프로토콜

2. authority: 도메인을 식별

3. path: 자원에 대한 정확한 경로

4. query: 요청한 작업을 나타냄

5. fragment: 리소스의 일부를 참조

HTTP 헤더는 모든 HTTP요청, 응답에서 서버와 클라이언트가 주고받은 문자열의 목록입니다. 요청하는 경우의 헤더에는 받게 될 데이터에 대한 특정한 정보나 혹은 요청하는 브라우저에 대한 정보가 있습니다.

 

서버는 요청을 받으면 HTTP응답을 합니다. 응답에 첨부된 body를 통해 관련된 모든 헤더와 HTML문서를 찾을 수 있습니다.

응답 헤더에는 응답한 서버의 위치 같은 추가적인 정보가 있습니다. 그리고 응답을 통해 드디어 HTML을 받을 수 있습니다. HTML을 보면 css, javascript 파일에 대한 각각의 참조가 있습니다. 이 파일들은 브라우저가 이 링크들을 만날 때까지는 요청되지 않습니다. 나중에 HTML 파싱단계에서 브라우저가 이 링크를 만날때 실행될 겁니다. 이 단계에서는(Data Fetching) 오직 HTML만이 서버로 요청되고 응답됩니다. 

첫 요청에 대한 응답은 데이터의 첫 byte가 포함되어 있습니다. Time to First Byte(TTFB)는 사용자가 주소창에 웹사이트 도메인이름을 쳐서 보낸 리퀘스트와 응답으로 온 HTML의 첫 패킷(보통 14kb)을 받는 순간까지의 시간입니다.

 

TCP Slow Start and congestion algorithms

TCP는 전송되는 패킷의 순서를 보장하기 때문에 서버는 일정 개수의 세그먼트를 보낸 후 클라이언트로부터 ACK패킷을 받아야 합니다. 잘 받았다고 서버에 확인시켜 주면 서버는 안심하고 다음 세그먼트를 보낼 수 있습니다. 만약 서버가 각 세그먼트 전부에 대해 ACK를 기다리면 용량이 그리 크지 않은 네트워크의 경우에도 클라이언트가 너무 많은 ACK를 응답해야 할 것이고 전송 시간이 길어질 수 있습니다. 반대로 한 번에 너무 많은 세그먼트를 보내면 혼잡한 네트워크일 때 클라이언트가 세그먼트를 받지 못할 수 있고 클라이언트의 ACK응답도 오래 걸려서 서버가 세그먼트를 다시 보내게 될 수도 있습니다.(서버입장에서는 보낸 세그먼트에 대한 응답이 없으니 다시 보내게 된다는 말 같습니다)

그래서 효과적으로 전송하는 세그먼트의 수의 균형을 맞추기 위해 TCP Slow Start 알고리즘이 사용됩니다.

TCP Slow Start는 네트워크 연결 속도의 균형을 잡아주는 알고리즘입니다. 첫 데이터 패킷은 14kb이고 작동방식은 전송되는 데이터의 양이 미리 정의된 임계값이 도달할 때까지 점진적으로 증가합니다. 서버로부터 각 패킷이 도착한 직후 클라이언트는 ACK message를 응답합니다. 네트워크 연결은 용량에 한계가 있기 때문에 서버가 너무 많은 패킷을 너무 빨리 보내면 패킷이 드롭됩니다.(클라이언트에 도착하지 않고 분실된다) 그럼 클라이언트는 이에 대한 ACK message를 보낼 수 없고 서버는 보낸 패킷에 대한 ACK를 받지 못하면 네트워크의 혼잡으로 해석합니다. 이때 congestion algorithms이 작동합니다. 패킷과 ACK message의 흐름을 모니터 하면서 최적의 트래픽을 결정하고 안정적인 트래픽 스트림을 만듭니다. 

 

전송할 세그먼트의 수는 1로 시작해서 지수승으로 증가합니다. 1,2,4,8...로 증가하면서 네트워크가 얼마나 많은 세그먼트를 안정적으로 보낼 수 있는지 점진적으로 늘려보다가 ACK가 수신되지 않으면 다음에는 값을 반으로 줄입니다. 이렇게 네트워크에서 혼잡제어를 하며 안정적인 트래픽 스트림을 확보합니다.

 

 

 

https://code-lab1.tistory.com/30

[네트워크] TCP 혼잡제어(congestion control)| AIMD, Slow Start | TCP Reno, Tahoe

https://developer.mozilla.org/en-US/docs/Web/Performance/How_browsers_work

Populating the page: how browsers work - Web performance | MDN

https://dev.to/arikaturika/how-web-browsers-work-part-2-with-illustrations-1gn5

How web browsers work - fetching data (part 2, with illustrations)🚀