얌생

HTTP에 대해 알아야할 것

1. Request <-> Resonpse 구조 + 비연결성

• 하나의 Request가 있으면 그에 대응하는 Response가 있다. 다시 말해,Request가 없으면 Response를 보내지 않는다.
• 연결을 유지하지 않기 때문에 리소스를 줄일 수 있어서 많은 트래픽을 빠르게 처리가 가능하다.

2. Stateless ( 무상태 )

• 연결을 한번 하고 끊기 때문에, 이전에 일어났던 일( 상태 )를 저장하고 있지 않는다.
• 매번 새로운 요청을 처리한다. ( 세션, 쿠키, DB로 해당 요청에 대한 정보를 임의로 저장해 처리하긴 한다. )

3. HTTP 프로토콜의 메세지 구조

• HTTP 프로토콜의 메세지 구조는 위 그림과 같다.
• 이 중에서 중요하게 살펴볼 부분은 헤더( header ) 부분인데, 메세지에 필요한 모든 부가 정보가 들어있고, 그림처럼 넣고 싶은 내용을 임의로 추가 할 수도 있다.

General Header

• Date : 현재 시간
• Pragma : 캐시제어( no-cache ), HTTP/1.0에서 쓰던 것으로 HTTP/1.1에서는 Cache-Control이 쓰인다.
• Cache-Control : 캐시 제어 + no-cache( 모든 캐시를 쓰기 전에 서버에 해당 캐시를 사용해도 되는지 확인 ) + public( 공유 캐시에 저장해도 됨 ) + max-age( 캐시의 유효시간을 명시 ) + private( '브라우저' 같은 특정 사용자 환경에만 저장 ) + must-revalidate( 만료된 캐시만 서버에 확인 ) + no-store( 캐시를 저장하지 않음 )
• Transfer-Encoding : body 내용 자체 압축 방식 지정. 본문에 데이터 길이가 나와서 야금야금 브라우저가 해석해 화면에 뿌려줄 때 이 기능을 사용한다. ( 'chunked'면 본문의 내용이 동적으로 생성되어 길이를 모르기 때문에 나눠서 보낸다는 의미 )
• Upgrade : 프로토콜 변경시 사용 
• Via : 중계( 프록시 )서버의 이름, 버전, 호스트명
• Content-Encoding : 본문의 리소스 압축 방식( transfer-encoding은 body 자체이므로 다르다 )
• Content-type : 본문의 미디어 타입(MIME) 예) application/json, text/html
• Content-Length : 본문의 길이
• Content-Language : 본문을 이해하는데 가장 적절한 언어. 예) ko
• Expires : 자원의 만료 일자
• Allow : 사용이 가능한 HTTP 메소드 방식 예) GET, HEAD, POST ...
• Last-Modified : 최근에 수정된 날짜
• ETag : 캐시 업데이트 정보를 위한 임의의 식별 숫자
• Connection : 클라이언트와 서버의 연결 방식 설정 HTTP/1.1은 kepp-alive로 연결을 유지하는게 디폴트

Request / Response Header

 ● request header form은 웹브라우저가 웹서버에 요청하는 것을 텍스트로 변환한 메세지들이다.

   ● Request Line : 어떤 웹서버로 접속( Host 부분 )해서, 어떠한 방식( HTTP / 1.1 )으로, 어떠한 메소드( GET )를 통해 무엇을( /doc/test/.html ) 요청했는지에 대한 메시지가 담겨있다. ( GET /test.html http 1.1 )

  ● Host : 요청하려는 서버 호스트 이름과 포트번호

  ● User-agent : 클라이언트 프로그램 정보 예) Mozilla / 4.0, Windows NT5.1 ( 이 정보를 통해 서버는 클라이언트 프로그램( 브라우저 )에 맞는 최적의 데이터를 보내줄 수 있다. )

  ● Referer : 바로 직전에 머물렀던 웹 링크 주소( 해당 요청을 할 수 있게된 페이지 )

  ● Accept : 클라이언트가 처리 가능한 미디어 타입 종류 나열 예) */* - 모든 타입 처리가능, application/json - json데이터 처리 가능

  ● Accept-charset : 클라이언트가 지원가능한 문자열 인코딩 방식

  ● Accept-language : 클라이언트가 지원가능한 언어 나열

  ● Accept-encoding : 클라이언트가 해석가능한 압축 방식 지정 예) gzip, deflate

  ● Content-location : 해당 개체의 실제 위치

  ● Content-disposition : 응답 메세지를 브라우저가 어떻게 처리할지 알려준다. 예) inline, attachment; filename='jeong-pro.xlsx'

  ● Content-Security-Policy : 다른 외부 파일을 불러오는 경우 차단할 리소스와 불러올 리소스 명시

      예) default-src 'self' -> 자기 도메인에서만 가져온다.

            default-src 'none' -> 외부파일은 가져올 수 없다.

            default-src https -> https로만 파일을 가져온다.

  ● If-Modified-Since : 여기에 쓰여진 시간 이후로 변경된 리소스를 취득. 페이지가 수정되었으면 최신 페이지로 교체하기 위해 사용된다.

  ● Authorization : 인증 토큰을 서버로 보낼 때 쓰이는 헤더

  ● Origin : 서버로 Post 요청을 보낼 때 요청이 어느 주소에서 시작되었는지 나타내는 값 ( 이 값으로 요청을 보낸 주소와 받는 주소가 다르면 CORS 에러가 난다. )

  ● Cookie : 쿠키 값 key-value로 표현된다. 예) attr1=value1; attr2=value2

● response header form은 웹브라우저가 요청한 메세지에 대해서 status 즉, 성공했는지 여부( 202, 400 등), 메세지, 그리고 요청한 응답 값들이 body에 담겨 있다.

  ● Location : 301, 302 상태코드일 때만 볼 수 있는 헤더로 서버의 응답이 다른 곳에 있다고 알려주면서 해당 위치( URL )를 지정한다.

  ● Server : 웹서버의 종류 예) nginx

  ● Age : max-age 시간내에서 얼마나 흘렀는지 초 단위로 알려주는 값

  ● Referrer-policy : 서버 referrer 정책을 알려주는 값 예) origin, no-referrer, unsafe-url

  ● WWW-Authenticate : 사용자 인증이 필요한 자원을 요구할 시, 서버가 제공하는 인증 방식

  ● Proxy-Authenticate : 요청한 서버가 프록시 서버인 경우 유저 인증을 위한 값

  ● 응답 상태 코드 ( 200, 202, 404 등 )

HTPP는 Application Layer 에서 동작하는 프로토콜이고, transport laye( 전송계층 )의 위에서 동작한다.

전송계층의 대표적인 프로토콜은 TCP / UDP가 있다.

HTTP는 TCP와 UDP 둘 중 하나의 연결을 통해서 동작한다. ( 결론적으로 TCP / UDP 프로토콜이 없으면 동작 불가 )

예외)

HTTP / 2 : 멀티플렉싱 기술의 등장으로 한번의 연결을 재사용하는 것이 가능하다.

HTTP / 3 : QUIC( UDP )위에서 동작한다.

TCP

HTTP는 비연결성이지만 TCP는 연결지향성이다.

• TCP는 데이터교환을 할 때 무조건 연결을 가진다.
• HTTP의 Req <-> Res가 발생할 때 밑에서 TCP 연결이 이루어진다.
• TCP는 3-handshake라고 하는 연결 과정을 가진다.

TCP 통신방법

 양방향 통신( Full-Duplex ) 순서

1. 서버는 접속 요청을 받기 위한 소켓을 연다. ( Listen )
2. 클라이언트는 소켓을 만들고, 서버에 접속을 요청한다. ( Connect )
3. 서버는 접속 요청을 받아서 클라이언트와 통신할 소켓을 따로 만든다. ( Accept )
4. 소켓을 통해 서로 데이터를 주고 받는다. ( Send & Receive 반복 )
5. 통신을 마치면 소켓을 닫는다. ( Close ( 상대방은 Receive로 인지할 수 있다. ) )

웹소켓( Websocket )

HTTP 프로토콜 위에서 동작하는 실시간 양방향 통신( Full-Duplex )

특징

 1. 실시간 통신

• 웹소켓은 연결이 활성화된 상태에서 빠르고 지속적인 메세지 교환을 허용한다. 이로 인해 에플리케이션은 사용자에게 지연 없는 인터랙션을 제공할 수 있다.

 2. 양방향 통신( Full-Duplex )

• 클라이언트와 서버가 동시에 서로에게 베세지를 보낼 수 있다. 이는 한 쪽이 다른 쪽의 메세지를 기다리지 않고도 독립적으로 메세지를 송수신 할 수 있음을 의미한다.

 3. 지속적 연결

• 웹소켓 연결이 수립되면, 그 연결은 클라이언트나 서버가 명시적으로 종료할 때까지 유지된다. 이는 오버헤드를 줄이고 빠른 데이터 전송을 가능하게 한다.

 4. 낮은 오버헤드

• 웹소켓은 데이터 패킷의 헤더가 매우 작기 때문에 오버헤드가 낮다. 이는 효율적인 네트워크 자원 사용을 가능하게 한다.

 5. HTTP와의 호환성

• 웹소켓은 HTTP 포트( 80과 443 )을 통해 작동하기 때문에 기존 웹 인프라와 잘 통합된다. 웹소켓 연결은 HTTP 연결을 통해 초기화되며, 이후 전이중 통신 채널로 전환된다.

각 프토토콜의 헤더 비교

HTTP 헤더

GET /data HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) Chrome/90.0.4430.212
Accept: application/json
Cookie: sessionToken=abcdef; userID=12345

• 보통의 HTTP Request Header의 일부분 ( 여기에 더해 General Header까지 추가하면 대략 수백 바이트의 양을 가진다. )

웹소켓 헤더

  0x81 0x05

• 연결 이후 데이터 교환할때의 websocket의 헤더
• 극도로 간소화되어 있지만, FIN 비트, Opcode, Mask 비트, Payload 길이 정보가 포함되어 있다.

TCP 패킷 헤더 

  Source Port:       54321
  Destination Port:  80
  Sequence Number:   123456789
  Acknowledgment Number: 987654321
  Data Offset:       5 (Header Length: 20 bytes)
  Reserved:          0
  Flags:             [ACK, PSH]
  Window Size:       65535
  Checksum:          0x1a2b
  Urgent Pointer:    0
  Options:           [No options]
  Payload Data:      "Hello, TCP!"

TCP 패킷의 구조

TCP 패킷, 종종 세그먼트라고 불리는 것은 다음과 같은 주요 부분으로 구성된다.

1. 소스 포트번호( 16비트 ) : 발신자의 포트 번호
2. 목적지 포트번호( 16비트 ) : 수신자의 포트 번호
3. 시퀀스 번호( 32비트 ) : 데이터 스트림 내에서 이 세그먼트의 위치를 식별하기 위한 번호
4. 응답 번호( 32비트 ) : 다음에 기대하는 데이터의 시퀀스 번호
5. 헤더 길이( 4비트 ) : 헤더의 크기를 나타냄
6. 예약된( 3비트 ) : 향후 사용을 위해 예약된 공간
7. 플래그( 9비트 ) : 연결 설정, 관리, 종료를 제어하는 다양한 플래그
8. 윈도우 크기( 16비트 ) : 수신자가 받을 준비가 되어 있는 버퍼의 크기
9. 체크섬( 16비트 ) : 오류 검사를 위한 값
10. 긴급 데이터 포인터( 16비트 ) : 긴급 데이터의 끝을 가리키는 포인터
11. 옵션( 가변 길이 ) : 필요에 따라 추가적인 옵션을 포함할 수 있음
12. 데이터( 가변 길이 ) : 실제 전송할 데이터

웹소켓의 연결방법은 TCP의 연결방법 ( 3-way-handshake)를 닮아있다.

웹소켓은 기본적으로 TCP 연결 위에서 작동하기 때문에, 웹소켓 연결을 시작하기 전에 TCP의 표준 연결 방법인 3-way handshake가 수행된다. 하지만 웹소켓은 이후에 추가적인 핸드셰이크 과정을 진행해 웹소켓 특유의 연결을 완성한다.

웹 브라우저

웹 브라우저는 인터넷 브라우저라고도 불리며, 웹 서버로부터 정보를 요청하고 받아 사용자에게 보여주는 소프트웨어다.

웹 브라우저는 인터넷 상의 다양한 정보를 조회하고 접근한다. 우리가 일반적으로 사이트에 접속했을때,

HTML, CSS, Javascript 파일을 전달받아 이를 해석하고 화면에 보여준다.

이 과정에서 웹 브라우저는 정적(Static)파일과 동적(Dynamic)정보를 처리하게 된다. 정적 웹페이지는 서버에서 브라우저로 전송되는 그대로 표시되나, 동적 웹 페이지는 서버로부터 데이터를 받아 브라우저가 실시간으로 내용을 생성 또는 변경한다.

대표적인 웹 브라우저에는 Internet Explorer, Chrome, Firefox, Safari 등이 있다.

웹 브라우저의 통신방식

브라우저의 통신 방식은 아래와 같다.

 1. 사용자가 웹 브라우저의 주소창에 URL을 입력한다.

 2. 웹 브라우저는 입력받은 URL을 DNS 서버로 전달해 해당 IP 주소를 찾게 된다.

 3. DNS 서버는 도메인 이름을 IP 주소로 변환한다.

 4. 웹 브라우저는 해당 IP 주소로 HTTP 요청을 전달한다.

 5. IP 주소에 연결된 웹 서버는 요청을 받아 처리한다.

 6. 웹 서버는 처리 결과를 HTTP Response로 브라우저에게 전달한다.

 7. 웹 브라우저는 받은 HTTP Response을 바탕으로 사용자에게 표시한다.

URL

URL ( Uniform Resource Locator )은 인터넷 상의 리소스 위치를 나타내기 위해 사용한다. ( = 인터넷 상의 주소 )

웹 브라우저는 주소창에서 원하는 인터넷 리소스를 조회하기 위해 URL을 입력한다.

여기서 URL은 <프로토콜>://<도메인 명>:<포트>/<경로>의 구조를 가지며,

이는 웹서버의 특정한 리소스의 위치를 가리키게 된다.

예를 들어, 'http://cafe.naver.com/joonggonara' 라는 URL을 분석해 보면,

'http'는 프로토콜을 나타내고, 'cafe.naver.com'은 'naver.com'이라는 메인 도메인 명과 'cafe'라는 서브 도메인 명으로

이루어져 있으며, 'joonggonara'는 서버에서 리소스 경로를 가리키게 된다. 

즉, 중고나라 라는 카페를 가르키게 된다.

이렇게 URL을 통해 웹 브라우저는 웹 서버의 특정 리소스에 대한 위치를 파악하고 요청을 전달하게 된다.

웹 브라우저에 'cafe.naver.com' 이라고 입력하면, 브라우저는 'cafe.naver.com' 서버의 메인 페이지를 요청하고,

해당 서버가 보내는 데이터를 받아 웹 브라우저에 보여줌으로써 웹 페이지를 조회할 수 있게 된다.

DNS

DNS ( Domain Name Service )는 도메인 이름을 중개해서, IP로 변경해주는 서비스를 제공한다. ( = 인터넷 상의 연락처 )

만약 'blog.naver.com' 주소를 웹 브라우저 주소창에 입력하면 대응 되는 정보를 조회하게 된다.

'blog.naver.com'과 같이 영어, 숫자, 특수문자롸 이루어진 URL을 IP로 변환해주는 역할을 하는 서비스를

DNS ( Domain Name Service ) 라고 하는것 이다.

인터넷 상의 각각의 리소스들은 고유의 IP 주소를 가지고 있다.

이 IP 주소는 숫자와 점 ( . )으로 이루어져 있어, 사람이 외우기 어렵고, 무슨 정보를 나타내는지 이해하기 어렵다.

이 때 DNS를 이용하면, 사용자가 IP를 사용하지 않고도 더욱 편리하게 해당하는 인터넷의 리소스에 접근할 수 있다.

DNS는 인터넷의 주소록 또는 연락처와 같은 역할을 하게 된다. 

HTTP

HTTP ( HyperText Transfer Protocol ) 는 문서( 하이퍼텍스트 )를 전송하기 위한 프로토콜로,

서버와 클라이언트 사이에서 어떻게 메세지를 교환할지를 정해 놓은 규칙이다.

요청 ( Request )과 응답 ( Response )으로 구성되어 있고, 일반적으로 80번 포트를 사용한다.

서버와 브라우저의 관계로 간단히 설명하자면,

1. 브라우저는 서버에게 자신이 원하는 페이지를 요구( Request )한다.

2. 서버는 브라우저가 원하는 페이지가 있는지 확인하고, 있을 경우 해당 페이지에 대한 데이터를

    반환( Response )해준다. 

3. 브라우저는 서버에게 전달 받은 데이터를 기반으로 브라우저에 그려준다.

위 경우에 한해 데이터는 어떠한 데이터든 주고 받는게 가능하다.

HTTPS

HTTPS는 HTTP를 기반으로 데이터 통신의 안전성을 높이기 위해 암호화 기능이 포함된 통신 프로토콜이다.

일반적으로 443번 포트를 사용한다. 

엄밀히 말해 HTTPS는 HTTP와 별개의 프로토콜은 아니다.

HTTPS는 단순히 HTTP 프로토콜을 통해 TLS/SSL 암호화를 사용한다.