[발표] 요청과 응답 사이의 흐름을 따라가보자

[상황설정]
유저가 티스토리에 들어가서 글을 보기위해 해당글을 클릭했다.
https://supersett-diary.tistory.com/232 을 접속할때 일어나는 일에 대해 설명해보세요.

0. 시작하기에 앞서서

• 웹을 지탱하는 가장 중요한 두 기술은 HTML과 HTTP이다. HTTP를 이해한다는것은 웹이 어떤식으로 동작하는지에 대한 이해를 뜻하는데, 정확한 근거에 기반한 맞는 기술적 판단을 하는데 도움이 된다.

 

1. DNS 서버 찾기

▶DNS?

• 도메인을 이용해서 한눈에 파악하기 힘든 IP 주소를 보다 분명하게 나타낼 수 있다.

▶HTTP

• HTTP는 Hypertext Transfer Protocol의 약자다. 즉 Hypertext 인 HTML(Hyper Text Markup Language)을 전송하기 위한 통신규약을 의미한다.
• 인터넷 자체가 전세계의 컴퓨터와 네트워크 장치 사이에서 대중적으로 사용되는 TCP/IP에 기초하고 있는데, TCP와 IP가 층을 이루는, 패킷 교환 네트워크 프로토콜의 집합이다. 

 

▶HTTP와 HTTPS의 차이점 

• SSL(Secure Sockets Layer)이라는 보안계층이 전송계층 위에 올라간다. HTTPS는 SSL 위에 HTTP를 얹어서 보안이 보장된 통신을 하는 프로토콜이다. 이 통신 방식을 SSL 암호화 통신 이라고도 한다.

실제 HTTPS 연결 과정이 성립되는 흐름을 살펴보면 다음과 같다.

1. 클라이언트(브라우저)가 서버로 최초 연결 시도를 함
2. 서버는 공개키(엄밀히는 인증서)를 브라우저에게 넘겨줌
3. 브라우저는 인증서의 유효성을 검사하고 세션키를 발급함
4. 브라우저는 세션키를 보관하며 추가로 서버의 공개키로 세션키를 암호화하여 서버로 전송함
5. 서버는 개인키로 암호화된 세션키를 복호화하여 세션키를 얻음
6. 클라이언트와 서버는 동일한 세션키를 공유하므로 데이터를 전달할 때 세션키로 암호화/복호화를 진행함

출처: https://mangkyu.tistory.com/98 [MangKyu's Diary:티스토리]

▶HTTP와 HTTPS 언제 쓸까?

개인 정보와 같은 민감한 데이터를 주고 받아야 한다면 HTTPS를 이용해야 하지만, 노출이 되어도 괜찮은 단순한 정보 조회 등 만을 처리하고 있다면 HTTP를 이용하면 된다.

---

2. 연결(Transmission Control Protocol Connection)

▶왜? TCP를 쓸까?

[ TCP 특징 ]

• 연결형 서비스로 가상 회선 방식을 제공한다.
• 3-way handshaking과정을 통해 연결을 설정하고 4-way handshaking을 통해 해제한다.
• 흐름 제어 및 혼잡 제어.
• 높은 신뢰성을 보장한다.

[ UDP 특징 ]

• 비연결형 서비스로 데이터그램 방식을 제공한다
• 정보를 주고 받을 때 정보를 보내거나 받는다는 신호절차를 거치지 않는다.
• UDP헤더의 CheckSum 필드를 통해 최소한의 오류만 검출한다.
• 속도가 빠르며 네트워크 부하가 적다는 장점이 있지만 신뢰성있는 데이터의 전송을 보장하지는 못합니다. 그렇기 때문에 신뢰성보다는 연속성이 중요한 서비스 예를 들면 실시간 서비스(streaming)에 자주 사용

---

▶TCP 3,4 way handshake

TCP 3way handshake

양쪽 모두 데이타를 전송할 준비가 되었다는 것을 보장하고, 실제로 데이타 전달이 시작하기전에 한쪽이 다른 쪽이 준비되었다는 것을 알수 있도록 한다.

(SYN, ACK 패킷을 주고받으며, 임의의 난수로 SYN 플래그를 전송하고, ACK 플래그에는 1을 더한값을 전송. 정확한 순서는 SYN(n) -> ACK(n + 1), SYN(m) -> ACK(m + 1) 순으로 일어난다.)

 

 

---

▶ TCP의 느린 시작 (slow start)

전송속도는 커넥션이 만들어진 지 얼마나 지났는지에 따라 달라질 수 있다. 시간이 지나면서 자체적으로 튜닝되어서, 처음에는 커넥션의 최고속도를 제한하고 데이터가 성공적으로 전송됨에 따라서 속도 제한을 높여나간다.

갑작스러운 부하와 혼잡을 방지하는 데 쓰인다. 

---

▶HTTP 커넥션의 성능을 향상시킬 수 있는 여러 최신 기술

1. 병렬 커넥션 parallel
   • 여러 개의 TCP 커넥션을 통한 동시 HTTP 요청
2. 지속 커넥션 persistent
   • 커넥션을 맺고 끊는 데서 발생하는 지연을 제거하기 위한 TCP 커넥션의 재활용
3. 파이프라인 커넥션 pipelined
   • 공유 TCP 커넥션을 통한 병렬 HTTP 요청
4. 다중 커넥션 multiplexed
   • 요청과 응답들에 대한 중재 (실험적인 기술이다..)

---

▶병렬커넥션 vs 지속커넥션

병렬 커넥션 3가지 단점

1. 트랜잭션마다 새로운 커넥션을 맺고 끊어서 시간과 대역폭이 소요된다.
2. 각각의 새 TCP는 느린 시작 때문에 성능이 떨어진다.
3. 실질적으로 연결 가능한 커넥션 수에 제한이 있다.

지속 커넥션은 이에 비해 몇 개의 장점이 있다. 커넥션을 맺기 위한 작업과 지연을 줄이고, 튜닝된 커넥션을 유지하고, 커넥션의 수는 줄여준다.

하지만 커넥션을 잘못 관리하면 커넥션은 점차 쌓이게 될 것이고, 이는 로컬 리소스와 클라이언트, 서버의 리소스에 불필요한 소모를 방치하게 된다.

---

3. 요청

▶HTTP 메세지

• 시작줄은 어떤 메세지인지 서술하고, 헤더 블록은 속성을, 본문은 데이터를 담고있다.

PUT

The PUT method requests that the state of the target resource be
created or replaced with the state defined by the representation
enclosed in the request message payload
-- rfc7231

• 서버가 요청의 본문을 가지고 요청 URL의 이름대로 새 자료를 만들거나,
• 이미 URL이 존재한다면, 본문을 사용해서 교체한다.

POST

• 서버에 입력 데이터를 전송하기 위해 설계되었다.
• request의 body 타입은 Content-Type 헤더(header)에 따라 결정된다.
• POST는 비멱등성을 갖는다. 같은 POST를 연속적으로 보낸다면 명령을 여러 번 내린 것처럼 부가적인 효과를 가져올 것입니다.

---

# 프락시 서버

▶왜 사용할까?

• 보안을 개선하고
• 성능을 높여주며
• 비용을 절약한다.
• 부가적인 가치를 주는 여러 유용한 웹서비스를 구현하기 위해 트래픽을 감시하고 수정한다.
• 오늘날 웹 요청의 상당수가 프락시를 지나간다.
  = 동시에 성능상의 이유로 세계 곳곳에 흩어져 있는 대리 캐시 저장고에 콘텐츠를 복제해두는 방식이 흔해지고있다.

 

• 프락시가 점점 흔해지면서, 프락시를 넘나드는 메세지의 흐름을 추적하고 문제점을 찾아내는 것도 필요한 일이 되었다. 

TRACE

- 클라이언트에게 자신의 요청이 서버에 도달했을 때 어떻게 보이게 되는지 알려준다. 주로 진단을 위해 사용되는데, 요청이 의도한 요청/응답 연쇄를 거쳐가는지, 프락시나 다른 애플리케이션들이 요청에 어떤 영향을 미치는지 확인.

---

# 캐시 서버

▶왜 사용할까?

캐시는 자주 쓰이는 문서의 사본을 자동으로 보관하는 HTTP 장치다.
웹 요청이 캐시에 도착했을 때, 캐시된 로컬 사본이 존재한다면,
그 문서는 원서버가 아니라 캐시로부터 제공된다.

• 불필요한 데이터 전송을 줄여서, 네트워크 요금으로 인한 비용을 줄여준다.
• 캐시는 네트워크 병목을 줄여준다. 대역폭을 늘리지 않고도 페이지를 빨리 불러올 수 있게 된다.
• 캐시는 원서버에 대한 요청을 줄여준다. 서버는 부하를 줄일 수 있으며 더 빨리 응답할 수 있게 된다.
• 캐시는 거리로 인한 지연을 줄여준다. 페이지를 먼 곳에서 불러올수록 시간이 많이 걸린다.

▶재검사 Revalidation (신선도 검사)

• 원서버 콘텐츠는 변경될 수 있기 때문에,
  캐시는 반드시 그들이 갖고 있는 사본이 여전히 최신인지 서버를 통해 점검해야한다.!!
• 이러한 신선도 검사를 HTTP 재검사라 부른다.
• HTTP는 서버로부터 전체 객체를 가져오지 않고도, 콘텐츠가 여전히 신선한지 빠르게 검사할 수 있는 특별한 요청을 정의했다.
• 대부분의 캐시는 클라가 사본을 요청하였으며,
  그 사본이 검사를 할 필요가 있을 정도로 충분히 오래된 경우에만 재검사를 한다.

---

4. 처리 & 5. 응답

동적 콘텐츠 리소스 매핑

• 웹서버는 URI를 동적 리소스에 매핑할 수도 있다.
• 요청에 맞게 콘텐츠를 생성하는 프로그램에 URI를 매핑하는 것이다.
  • 웹서버들 중에서 어플리케이션 서버라고 불리는 것들은 웹서버를 복잡한 백엔드 어플리케이션과 연결하는 일을 한다.
• 어플리케이션 서버는 그에 대한 동적 콘텐츠 생성 프로그램이 어디에 있는지, 그리고 어떻게 그 프로그램을 실행하는지 알려줄 수 있어야 한다.
• 대부분의 웹서버는 동적 리소스를 식별하고 매핑할 수 있는 기본적인 매커니즘을 갖고 있다.
• URI의 경로명이 실행 가능한 프로그램이 위치한 디렉터리로 매핑되도록 설정하는 기능을 제공하는 웹서버도 있다.
• 서버가 실행 가능한 경로명을 포함한 URI로 요청을 받으면, 그 경로에 대응하는 디렉터리에서 프로그램을 찾아 실행하려 시도한다.

6. 종료

TCP 4way handshake

 TCP연결을 해제하는 단계로, 클라이언트는 서버에게 연결해제를 통지하고 서버가 이를 확인하고 클라이언트에게 이를 받았음을 전송해주고 최종적으로 연결이 해제된다. 단, 서버에서 소켓이 닫혔다고 통지해도 클라이언트 측에서는 일정시간 대기하는데, 혹시나 패킷이 나중에 도착할 수 있기 때문이다.