같은 실수를 반복하지 말자는 뜻에서, 내가 몰랐거나 혹은 알았어도 내 것이 아닌 것들을 계속해서 정리한다. 일단 면접에서 만족스럽게 답하지 못했으니 잘 모르는것은 틀림없고, 계속해서 넓혀나가면 되겠다.

브라우저에서 URL을 쳤을 때 무슨 일이 일어나는가?

https://aws.amazon.com/ko/blogs/mobile/what-happens-when-you-type-a-url-into-your-browser/

아마존에서 친절하게 설명을 잘 해놓았다.

https://channy.creation.net/blog

1. 이 주소를 브라우저에 칠 경우,

우선 브라우저에서 해당 주소가 어떤 프로토콜인지 판별한다. https는 Hypertext Transfer Protocol Secure를 가리키고, 전송 계층 보안(TLS) 방식을 통해 서버에 연결하도록 한다.
이 프로토콜을 통해 통신 데이터가 암호화되어 신용카드와 같은 방식으로, 암호화되어 서로간의 통신이 일어난다.

channy.creation.net 이것은 도메인명으로, 특정 서버의 ip 주소와 매칭된다.

/blog는 어떤 리소스를 요청하는 것인지 구체화 한다.

2. 웹 브라우저가 도메인명의 IP 주소 조회

브라우저는 어떤 서버에 요청할 것인가를 검색한다. 이 요청은 빨라야 하기 때문에, 다양한 곳에 캐싱을 해놓는데,

a. 브라우저 내부 고유한 캐시
b. 운영체제 캐시
c. 라우터의 로컬 네트워크 캐시
d. 회사네트워크 또는 인터넷 서비스 제공업체(ISP)의 캐시들을 확인한다.

여기서 캐싱된 정보를 찾을 수 없을 경우, DNS서버에서는 재귀적 DNS 조회를 실시한다.

3. 웹 브라우저와 서버간의 TCP/IP 연결

해당 패킷은 TCP/IP(Transmission Control Protocol/Internet Protocol) 프로토콜로 제어된다. 통신 회사간 경로인 라우팅 테이블을 따라서 IP주소가 존재하는 웹 서버를 찾는다.
요즘에는 콘텐츠 전송 네트워크(CDN)을 통해서 이 부분을 간소화하는 경우가 많다.

traceroute라는 명령어를 사용해서, 이를 직접 찾아볼 수 있다.

이러한 식으로, 해당 주소를 향해 연결을 시도했을 경우

총 64번의 연결 시도(hops가 있었고 패킷의 총 량은 52byte이다.)
이러한 요청들은 통신화사간 통로 라우팅 테이블을 따라 이동하여 목표 웹 서버를 찾게 된다.

서버를 찾게 될 경우,

http의 경우는 브라우저와 서버 간 평문 TCP 연결을 실시하게 된다.
https의 경우, (Transport Layer Security) 핸드셰이크라는 과정이 먼저 진행된다.

https://www.cloudflare.com/ko-kr/learning/ssl/transport-layer-security-tls/
TLS에 대한 내용은 다음과 같음

SSL과 TLS는 무엇이 다른가?

SSL
원래 웹에서의 데이터는 가로채면 누구나 읽을 수 있는 일반 텍스트 형태로 전송 되었다. 이러한 문제때문에 인터넷 통신의 개인정보 보호, 인증, 데이터 무결성을 보장하기 위해 Netscape가 1995년 처음으로 SSL을 개발하였다.

SSL(Secure Scokets Layer)은 암호화 기반 인터넷 보안 프로토콜이다. 전달되는 모든 데이터를 암호화하고 특정한 유형의 사이버 공격도 차단한다. SSL은 TLS(Transport Layer Security) 암호화의 전신이기도 한다.

SSL은 개인정보 보호를 제공하기 위해, 웹에서 전송되는 데이터를 암호화 한다. 따라서, 데이터를 가로채려해도 거의 복호화가 불가능하다.

SSL은 클라이언트와 서버간에 핸드셰이크를 통해 인증이 이루어진다. 또한 데이터 무결성을 위해 데이터에 디지털 서명을 하여 데이터가 의도적으로 도착하기 전에 조작된 여부를 확인한다.

SSL 프로토콜의 전반적인 기능을 구성하는 세 가지 하위 프로토콜은 다음과 같습니다.

핸드 셰이크 프로토콜 : 실제로 4 단계로 구성됩니다.
보안 기능 수립
서버 인증 및 키 교환
클라이언트 인증 및 키 교환
끝
레코드 프로토콜 : SSL의 레코드 프로토콜은 클라이언트와 서버 간의 핸드 셰이크가 성공적으로 완료된 후에 만 ​​나타납니다. 이 프로토콜은 다음과 같이 SSL 연결에 대해 두 가지 정의 된 서비스를 제공합니다.
기밀성 - 이는 핸드 셰이크 프로토콜에 의해 정의 된 비밀 키를 사용하여 수행됩니다.
무결성 - 공유 비밀 키 (MAC)는 메시지 무결성을 보장하는 데 사용되는 핸드 셰이크 프로토콜에 의해 지정됩니다.
경고 프로토콜 : 클라이언트 또는 서버가 오류를 식별하면 식별 당사자는 경고 메시지를 다른 당사자에게 전송합니다. 오류가 치명적인 경우 두 당사자가 SSL 연결을 빠르게 닫습니다.

TLS의 정의
TLS (Transport Layer Security)는 IETF (Internet Engineering Task Force) 표준화 표준으로 인터넷 표준 버전의 SSL을 목표로합니다. Netscape는 SSL 표준화를 원했기 때문에 IETF를 통해 프로토콜을 통과 시켰습니다. SSL과 TLS 간에는 큰 차이점이 있습니다. 그러나 주요 아이디어와 구현은 매우 유사합니다.

SSL과 TLS의 주요 차이점
SSL은 Fortezza를 지원하는 반면, TLS 프로토콜은 Fortezza / DMS 암호 제품군을 지원하지 않습니다. 또한 TLS 표준화 프로세스를 통해 새로운 암호 스위트를 훨씬 쉽게 정의 할 수 있습니다.
마스터 시크릿을 생성하는 SSL에서, 프리 마스터 시크릿의 메시지 다이제스트가 사용됩니다. 대조적으로, TLS는 의사 난수 함수를 사용하여 마스터 비밀을 생성합니다.
SSL 레코드 프로토콜은 각 블록을 압축 한 후 MAC (Message Authentication Code)을 추가하고 암호화합니다. TLS 레코드 프로토콜은 HMAC (해시 기반 메시지 인증 코드)를 사용합니다.
"인증서 없음"경고 메시지는 SSL에 포함되어 있습니다. 반면에 TLS는 경고 설명 (인증서 없음)을 제거하고 12 개의 다른 값을 추가합니다.
SSL 메시지 인증은 SSL 프로토콜 용으로 작성된 임시 정보로 주요 정보와 애플리케이션 데이터를 통합합니다. 반면 TLS 프로토콜은 HMAC라고하는 표준 메시지 인증 코드 만 사용합니다.
TLS 인증서에서 메시지를 확인하면 MD5 및 SHA-1 해시가 핸드 셰이크 메시지를 통해서만 계산됩니다. 반대로 SSL에서 해시 계산에는 마스터 비밀번호와 패드가 포함됩니다.
TLS의 완료 메시지와 마찬가지로 마스터 키와 핸드 셰이크 메시지에 PRF를 적용하여 만듭니다. SSL에서는 마스터 다이제스트와 핸드 셰이크 메시지에 메시지 다이제스트를 적용하여 생성됩니다.

이를 구글 개발자 도구에서 확인하면 다음과 같다.

다른 Network 요청들과 다르게, URL 자체를 요청하는 부분은 Timing 섹션에
DNS Lookup, Initial connection과 SSL(TSL 핸드쉐이크) 의 시간이 추가되어 있다.

https://developer.chrome.com/docs/devtools/network/reference/
에서 확인하면,

Queueing. The browser queues requests when:
There are higher priority requests.
There are already six TCP connections open for this origin, which is the limit. Applies to HTTP/1.0 and HTTP/1.1 only.
The browser is briefly allocating space in the disk cache
Stalled. The request could be stalled for any of the reasons described in Queueing.

Queueing은 엔진이 로드되는 과정에서 우선순위에 따라 데이터를 처리하는데, 이 우선순위 동안 기다리는 과정이라고 한다.
1. 우선순위에서 밀린 요청시간
2. 브라우저 오리진 하나당 6개의 tcp 연결을 유지할 수 있기 때문
3. 디스크 캐시에 파일을 받아올 부분을 할당하는 중
의 이유로 일어나는 시간이다.

Stalled 는 위 Queueing의 이유로 기다리게 되는 시간이라고 한다.

4. 웹 브라우저가 HTTP 요청을 서버로 전송

웹 브라우저가 연결되고, HTTP나 HTTPS 규약으로 통신을 시작하게 된다.
웹 브라우저는 해당 리소스의 내용을 서버에 위 프로토콜 중 하나로 요청하게 되고
여기에는 요청 라인, 헤더(메타데이터) 및 body가 포함된다.

요청 라인은 다음과 같이 생겼다.

1. GET, POST, PUT, PATCH, DELETE 또는 기타 HTTP 메소드,
2. 요청된 리소스를 가리키는 경로
3. 통신할 HTTP 버전
   을 포함한다.

예를 들어서, GET /hello-world HTTP/1.1
라고 한다면 해당 URL에서 hello-world라는 Resource를 Http 1.1을 이용해 GET 조회 요청을 하는 것이다.

요청의 헤더는 다음과 같다.

GET /hello-world/ HTTP/1.1
Host: jennapederson.dev // HTTP 2.0에서는 :authority: 필드가 대신한다.
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache
sec-ch-ua: " Not A;Brand";v="99", "Chromium";v="90", "Google Chrome";v="90"
sec-ch-ua-mobile: ?0
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.212 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
Sec-Fetch-Site: same-origin
Sec-Fetch-Mode: navigate
Sec-Fetch-User: ?1
Sec-Fetch-Dest: document
Referer: <https://jennapederson.dev/>
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.9
dnt: 1
sec-gpc: 1

body는 GET 요청이므로 존재하지 않는다.
body를 보내는 요청의 경우 header에서 Content-Type을 지정하여 어떤 타입의 body가 넘어가는지 지정해줄 수 있다.

5. 서버가 리퀘스트를 처리하고 응답

해당 리퀘스트를 request line, header, body에 따라 인식하고 서버가 어떤 응답을 보낼 것인지 결정하게 된다.
GET /hello-world/ HTTP/1.1,의 요청은 서버가 해당 위치 /hello-world/ 위치의 리소스를 컴파일하여 클라이언트로 보내주게 된다.

해당 응답은
1. 스테이터스 라인
2. 리스폰스 헤더
3. 해당 위치에 있는 리소스(HTML, CSS , Javascript or images or data)
으로 구성되고,

이렇게 생겼다.

HTTP/1.1 200 OK // 200 OK 이므로 요청 성공
Date: Tue, 25 May 2021 19:40:59 GMT
Server: Apache
X-Frame-Options: SAMEORIGIN
X-Powered-By: Express
Cache-Control: max-age=0, no-cache
Content-Type: text/html; charset=utf-8 
// 응답 body의 타입, html text이며 HTML5의 권장사항인 utf-8로 인코딩되었음
Vary: Accept-Encoding
X-Mod-Pagespeed: 1.13.35.2-0
Content-Encoding: br
Keep-Alive: timeout=1, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked

// get 요청이므로 자주 볼 수 있는 html 그 자체가 body가 된다
<!DOCTYPE html> 
<html lang="en">
<head>
    THE REST OF THE HTML

또한, 이 요청은 static html이 아니라 dynamic하게 요청 시 작성된 html을 응답하였는데,

ReactJS에서 index.js에서

이하의 내용을 js로 만들어서 보내주는 것과 같다.

6. 서버가 리퀘스트를 처리하고 응답

브라우저가 서버 응답을 받게 되면, 응답 헤더 부분을 확인하여 (Content-Type) 어떻게 해당 데이터를 렌더링할 것인지 정한다.
가장 자주 보게되는

content-type: application/json; charset=utf-8
//혹은
content-type: text/html; charset=utf-8

해당 요청이 html을 리턴했기 때문에 HTML을 렌더링 하면서 추가적인 JS, CSS, 이미지와 데이터를 요청하게 된다.

해당 사진에 따르면, css 요청이 추가로 브라우저에서 일어나게 되고

content-type: text/css

의 content-type으로 나오는 것을 알 수 있다.

참고한 url:

https://ko.gadget-info.com/difference-between-ssl