1일 1커밋 !

HTTP

HTTP는 정보를 주고 받을 때 사용하는 프로토콜이다. 처음에는 물리학자들이 논문을 주고받기 위해서 만들었다고 한다. 정보 요청 응답을 HTTP request, response 라 한다. 대게 클라이언트가 서버에게 request 를 보내면 이에 대해 서버가 클라이언트에게 response 를 보낸다. 이 응답에는 클라이언트가 요청한 사이트에 대한 정보가 담겨 있어 클라이언트는 웹 페이지 등을 열어볼 수 있다.

image

Resources

Static/Dynamic content

파일의 종류를 Dynamic/Static 파일로 나눌 수 있다.

  • Static : 클라이언트가 요청한 시간을 기점으로 이전에 존재하는 파일이다.
  • Dynamic : 클라이언트가 요청한 시간 이후에 만들어지는 파일이다. 주식, 잔고, 라이브이미지 등 프로그램이 정보와 파라미터를 바탕으로 정보를 통해 실시간으로 만들어지는 파일이다.

image

Media Types

인터넷으로 주고 받는 데이터를 더 다양하게 하기 위한 목적으로 확장되었다.

  • MIME (Multipurpose Internet Mail Extensions) : 이메일 안에 첨부파일이 무엇인이 명시하기 위한 미디어 타입이다. 개발자 및 사용자가 쉽게 알 수 있도록 text로 변환되어 있다.

image

URI, Uniform Resource Identifier

클라이언트가 서버에게 X라는 파일을 요청한다면 어떻게 X를 인식하고 찾아 다시 응답할 것인가?? 이를 위해 식별자를 만들어냈다. HTTP는 서버 안에 파일을 식별하기 위한 구조로, 인터넷에 특정 리소스를 찾아가기 위한 Address라고 할 수 있다. 따라서 유니크해야하고 위치에 대한 정보다 필요하다.

URL/N (Uniform Resorce Location/Name)

www.example.com/index.html -> example.com이라는 컴퓨터를 찾아가 root 디렉토리 밑에 index.html 파일을 찾아간다!

Transaction

  • HTTP request

클라이언트가 서버에게 파일을 달라고 요청할 때 사용되는 것이다. GET은 해당 위치에 있는 것을 요청하는 의미이다.

  • HTTP response

response로 200과 함께 Mime 이 클라이언트에게 도착한다. 아무 이상없이 잘 도착했음을 알 수 있다.

request에서도 클라이언트가 조건을 붙일 수 있다. 텍스트는 html으로만 주시고 언어는 영어만 주세요 같이 header 에 조건을 붙여 전달한다.

image

HTTP Methods

  • GET : 클라이언트가 서버로부터 받기를 원하는 리소스를 요청

image

  • HEAD : GET과 모두 똑같지만 파일 본체를 안보낸다. 파일을 제외한 모든 정보를 다 보낸다. 파일을 받기 전에 파일 사이즈가 궁금하거나 바뀐 내용이 있는지 확인할 때. 등등 여러 이유로 GET 전에 체크하고 싶을 때 사용한다.

image

  • PUT : 클라이언트가 파일을 주면서 이름을 주면 서버가 저장하는 것. 새롭게 자신의 파일에 저장되었으니 서버가 클라이언트에게 저장된 URL을 다시 알려준다.

image

  • POST : 파일이 아니라 값을 주고받는다. 파일이 아닌 글자! 클라이언트가 서버에게 데이터를 보내서 서버가 다이나믹한 콘텐츠를 만들 때 등 사용한다.

image

  • TRACE : 프록시가 있는 지 없는 지 확인하는 메소드. 프록시가 인식하면 자신을 통과했다고 메세지를 추가해 넣는다. 자신을 알리고 싶지 않으면 넣지 않는 경우도 있다.

image

  • OPTION : 지원하는 모든 옵션을 알려달라는 요청이다. 보안상의 이유로 대부분의 사이트에서 응답이 오지는 않는다. 만약 오면 GET, POST, PUT … 등등 으로 온다.

image

  • DELETE : 서버로부터 리소스를 삭제한다.

image

redirect ::파일이 다른 곳에 있으니 다른 곳으로 가라고 알려준다!

image

Status Codes

HTTP 응답에는 여러 코드들이 존재하며 이를 통해 어떤 상태인지 대략적으로 알 수 있다.

  • 200 : 모두 정상적으로 작동한다.
  • 302 : redirect
  • 404 : not found. 해당 파일을 찾을 수 없다.

이외에도 다양하고 많은 상태 코드가 존재한다.

image

Messages

실제로 클라이언트와 서버가 주고받는 메세지의 예시이다.

클라이언트는 서버에게 GET 방식으로 /tools.html 을 요구한다. 이는 서버의 루트 디렉토리에 존재하는 tools.html 파일을 요청하는 것이다. 이와 함께 request headers 에는 응답받을 형식이나 언어를 지정해서 요청한다.

서버는 이를 받고 클라이언트에게 응답을 한다. response message 의 가장 첫 줄을 보면 200 OK 를 확인할 수 있다. 이는 서버가 모두 정상적으로 클라이언트에게 요청에 응답했다는 뜻이다. response headers 에도 추가 부가적인 정보들이 담겨있으며 실제 클라이언트가 요청한 내용이 response body 에 담겨 클라이언트에게 전달된다.

image

TCP

HTTP 통신 간에 신뢰성을 가져야하기 때문에 TCP를 사용하도록 권장하며 TCP위에 HTTP가 올라간다. TCP는 연결, 해제 과정을 통해 오류가 발생하더라도 복구해줄 수 있기에 신뢰성이 높다.

image

Proxy

자신을 거쳐가는 트래픽을 모두 들여다보면서 클라이언트가 서버에 접속하려했을 때 접속 불가한 경우 프록시가 접근을 막는다. 차단을 막지 않고 로그에 기록하는 어플리케이션과 연동도 가능하다. 전송 속도가 안좋은 곳에서는 압축 후 보내든가 자신이 파일을 가지고 있다가 바로 보내주는 캐시 역할도 할 수 있다.

image

HT4TP 2.0

HTTP의 기존 문제점과 해결책

  1. 바이너리 프로토콜 : 텍스트 기반으로 주고받으면 통신 속도에 문제가 발생한다. 글자를 숫자로 바꾸는 프로세싱 시간이 문제이므로 처음부터 0과 1을 보내자.

image

  1. 멀티플렉싱 : 가장 큰 단점은 HTTP req를 순서대로 req를 받고 res도 순서대로 와야한다. 동기적으로 작동했지만 HTTP 2.0은 다수의 요청/응답을 동시에 처리할 수 있다. 서버가 준비되면 바로바로 응답을 보내 비동기적으로 이루어지는 것이다.

image

  1. 헤더압축 : 헤더에는 쓸데없이 주고 받는 것이 존재한다. 안바뀌는 메세지들은 반복적으로 계속 주고받을 필요가 없으니 반복적으로 사용되는 헤더를 줄인다. 그걸 인덱스값으로 바꾸고 static table에서 따로 관리한다.

image

  1. 우선순위 설정 : 중요한 리소스의 처리 지연을 방지한다. 우선순위 높은 요청, 응답은 더 빠르게 간다.
  2. 서버 푸시 : HTTP는 요청하지 않으면 응답하지 않는다. 클라이언트가 요청하지 않아도 요청할만한 것들을 서버가 미리 보낼 수 있다. 컨텐츠 리프레쉬, 알람 등등.

image

HTTP 3.0

UDP에 올라가는 HTTP이며 QUIC 이라고도 불린다. 2.0에 있던 멀티플렉싱, 압축을 고려한 상태에서 TCP의 문제를 개선했다.

image

기존에 연결에 시간이 오래 걸리고, flow control, congestion control, bandwidth 등 대역폭 조정하느라 느린 점을 개선했다.

TCP를 개선하려면 커널이 아닌 user space에서 동작하도록 커널에서 구현해야했었다. 하지만 QUIC은 UDP이므로 에러검출 등은 어플리케이션 레벨에서 작동한다.

QUCI은 기존 HTTP에 비해 처음 연결시간이 줄어든다! 암호화, 보안을 추가로 한다. TCP를 자체로 건들이기 어려우니 레이어를 차곡차곡 쌓는다. UDP 위에서 에러검출과 컨트롤을 올린다.

Fast Establishment

TCP는 SYN, ACK, ACK 외에도 프로토콜 등등 왔다갔다가 굉장히 많다 QUIC은 오고 가면 끝! 처음 연결 시 100ms, 한 번 연결됐었으면 0 ms

image

Error Correction

HTTP/2는 TCP 하나의 줄이므로 속도 조절이 어렵고 앞에서 멈추면 막힌다 QUIC는 줄 하나가 아니라 여러 줄이므로 하나가 에러, 느려진다고 전체가 느려지지는 않는다.

image

커널 아래있는 애들은 밀결합되어 오버헤드가 작다. 어플리케이션은 오버헤드가 크다. 하지만 요즘은 그렇게 오버헤드가 크지 않아 자유도가 높아졌다. 따라서 UDP 위에 어플리케이션을 쌓아 성능을 높일 수 있었다.

image

SIP (Session Initiation Protocol)

미디어 세션을 만들고 수정, 연결을 시작하는 모든 것들이 세션. 실시간으로 음성, 영상, 채팅 등등 모든 것을 끌어안아 위에서 연결한다. HTTP의 text based를 보고 감명받았다. 인스턴스 메세지나 화상 모두 invite 하고 OK 하고 ACK보내면 연결. BYE 메세지와 OK 면 연결 해제. 채팅방을 만들고 없애거나 화상통화를 시작하거나 끝낼 때 모두 사용한다.

image

  • 실어나르는 애가 SIP, 실리는 애가 SDP(Session Description Protocol) 로 따로 구분한다.
  • User Agent Client / Server ( UAC / UAS )
  • Registrar : 바뀌는 것은 IP Address , 안바뀌는 것은 라인, 카카오톡, 아이디.
  • 통신하려면 상대방의 현재 IP 주소가 필요하다
  • SIP 아이디를 Ip Address로 매핑하는 것이 필요하다. 네트워크 주소가 바뀔때마다 등록

  • 카카오톡에 로그인하는 것이 카카오톡 서버에 자신의 아이디에 IP 주소를 저장

  • Proxy 서버 :: 일단 받아주고 Redirect 서버에 상대방의 위치가 어디에 있는지 물어본다. Redirect 서버는 Location Server에서 상대방의 위치를 찾아 알려주면 둘이 통신할 수 있도록 이어준다. 채팅방인 경우에 1:n 전송도 가능

image

업데이트:

댓글남기기

참고