on
HTTP (첫 번째 요약)
HTTP (첫 번째 요약)
인프런 - 김영한님의 HTTP
HTTP (첫 번째 요약)
여기에 있는 내용은 모두 인프런 - 김영한님의 강의를 보고 정리한 내용입니다.
제일 좋은 공부 방법은 이런 요약을 보는 것이 아닌 직접 강의를 보고 이해해서 나의 것으로 만드는 게 중요하다고 생각합니다.
IP(Internet Protocol)의 역할
지정한 IP 주소에 데이터를 전달한다.
통신 단위인 패킷을 전달한다.
IP 패킷의 목적
IP 패킷에는 출발지 IP와 목적지 IP가 있습니다.
먼저 출발지 IP인 클라이언트부터 IP 패킷을 보냅니다.
그렇게 많은 노드들을 통해 IP 패킷이 보내지면 결국에는 목적지 IP인 서버까지 도달하게 됩니다.
받은 IP 패킷을 통해 서버에서 다시 클라이언트로 서버패킷을 전달합니다.
IP 프로토콜의 한계
비연결성 만약 패킷을 받을 상대가 인터넷이 끊겨도 즉, 서비스 불능 상태여도 패킷을 그대로 전송합니다.
비신뢰성 패킷을 전송했는데 중간에 패킷이 사라지거나 패킷이 순서대로 오지 않은 경우
프로그램 구분 한 IP로 여러 애플리케이션을 돌릴 경우
이러한 IP 프로토콜의 한계를 TCP가 해결해줍니다.
TCP
TCP는 IP 패킷 안에 TCP 정보가 들어갑니다.
TCP에는 출발지 PORT, 목적지 PORT, 전송 제어, 순서, 검증 등의 정보가 들어있습니다.
TCP 특징
TCP란 전송 제어 프로토콜(Transmissioni Control Protocol)입니다.
연결지향 - TCP 3 way handshake
데이터 전달 보증
순서 보장
신뢰성 있는 프로토콜 -> 대부분 TCP를 사용합니다.
TCP 3 way handshake
클라이언트 -> 서버로 SYN 이라는 메시지를 보내서 접속을 요청합니다. 서버 -> 클라이언트로 ACK 라는 메시지를 통해 접속 요청에 대한 응답을 해주고 다시 서버쪽에서 요청을 하기 위해 SYN 을 보냅니다. 즉, 이때는 SYN+ACK 이렇게 메시지를 보냅니다. 클라이언트 -> 서버로 서버에 대한 요청을 응답해주기 위한 ACK 메시지를 보냅니다.
위 3 과정을 하게 되면 클라이언트와 서버간에 신뢰할 수 있게 되어 연결을 할 수 있게 됩니다.
이것을 3 way handshake 라고 합니다.
여기서 알아야 할 점은 3 way handshake는 물리적으로 서로 연결된 것이 아니라 논리적으로 연결된 것을 말합니다.
즉, "아, 서로 연결이 잘됐나 보다~" 하고 판단을 내립니다.
데이터 전달 보증
클라이언트에서 서버로 데이터를 전송합니다. 서버에서 클라이언트로 데이터를 잘 받았다고 전송합니다.
위 과정이 이루어져야 신뢰성 있는 통신이 가능합니다.
만약 데이터를 전송했는데 그에 대한 응답이 없으면 정상적으로 연결이 되지 않은 겁니다.
순서 보장
클라이언트에서 서버로 패킷1, 패킷2, 패킷3 ... 순서로 전송합니다. 만약 서버에서 패킷1, 패킷3, 패킷2 ... 순서로 받았다면 순서가 맞지 않으므로 서버에서 클라이언트로 다시 패킷2부터 보내라고 요청합니다. -> 순서가 보장됩니다.
이렇게 순서가 보장이 될 수 있는 이유는 TCP의 전송 제어, 검증 등의 정보 때문에 가능한 것입니다.
그래서 TCP는 신뢰성 있는 프로토콜이라고도 불리는 겁니다.
UDP
UDP는 TCP과 같은 계층에 있습니다.
UDP 특징
사용자 데이터그램 프로토콜 (User Datagram Protocol)
기능이 거의 없습니다.
연결지향 - TCP 3 way handshake X
데이터 전달 보증 X
순서 보장 X
데이터 전달 및 순서를 보장하지 않지만 그 만큼 속도가 빠르다는 장점이 있습니다.
이는 즉, IP와 거의 같고, 여기에 PORT와 체크섬(검증)이 추가됩니다.
위에서는 IP는 한 IP에 여러 애플리케이션이 돌아갈 경우에 패킷을 구분할 수가 없어서 한계점이라고 했습니다.
만약 여기에 PORT가 추가되면 한 IP에 각각의 애플리케이션마다 패킷을 구분할 수가 있습니다.
결국 TCP와 UDP의 결정적 차이는 '속도' 입니다.
TCP는 3 way handshake라는 과정을 거쳐야 하기 때문에 속도가 더디지만,
UDP는 그런 과정이 없는 하얀 도화지이기 때문에 속도가 더 빠릅니다.
PORT
만약 내 pc 에 여러 어플리케이션을 돌리고 있다고 가정해보자. (게임, 화상 통화, 웹 브라우저 요청 ...)
이 경우에는 여러 서버랑 통신하게 됩니다.
여기서 각 서버쪽에서 패킷들이 내 pc 로 올텐데 이 때!! 패킷들이 게임 패킷인지, 화상통화 패킷인지, 웹 브라우저 응답 패킷인지 구분을 할 수가 없습니다.
그래서 패킷을 구분 지을 수 있도록 'PORT' 를 사용합니다.
즉, IP는 어떤 출발지와 목적지를 구분하기 위해 출발지 IP, 목적지 IP가 있고
PORT는 한 IP 내에 여러 어플리케이션이 돌고 있을 때 각 패킷을 구분짓기 위해 사용합니다.
PORT는 0 ~ 65535 할당이 가능합니다.
0 ~ 1023 은 잘 알려진 포트이므로 사용하지 않는 것이 좋습니다. FTP : 20, 21 TELNET : 23 HTTP : 80 HTTPS : 443
DNS
내 PC와 상대 PC를 구분짓기 위해 출발지 IP와 목적지 IP 라는 것을 사용했었습니다.
하지만 IP는 100.100.100.1 처럼 숫자로 되어 있기 때문에 외우기가 쉽지 않습니다.
그래서 사람들이 외우기 쉽게 하기 위해 IP에 이름을 짓습니다. 이것이 바로 도메인명 입니다.
예를 들어 구글이면 구글 사이트가 만약 IP가 123.456.673.2 이렇게 되어 있으면 사람들이 굉장히 구글 사이트에 들어가기가 힘들 것입니다.
하지만 구글 이라는 타이틀로 도메인을 설정하면 사람들이 쉽게 접근할 수 있겠죠. (ex. www.google.com)
URI
URI(Uniform Resource Identifier)는 리소스를 식별하는 통합된 방법이란 뜻입니다.
URI 안에 URL과 URN이 있습니다.
URL은 https://www.naver.com 처럼 웹 브라우저에 주소 적는 것이 URL 입니다.
URN은 urn:example:animal:ferret:nose 처럼 주소처럼 이름을 부여하는 것이 URN 입니다. URN의 단점은 중간에 이름을 넣으면 찾기 매우 어렵습니다. -> 거의 URL만 사용.
웹 브라우저 주소를 검색했을 때 무슨 일이 벌어질까?
면접에서도 나올만한 질문인 https://www.naver.com 이 주소를 쳤을 때 어떤 일이 벌어질까요?
가장 먼저 DNS 를 조회합니다. (www.naver.com) -> IP 조회 다음으로 PORT 를 조회합니다. 여기까지 IP와 PORT 정보를 찾아냅니다. HTTP 요청 메시지를 생성합니다. -> 전송 데이터 위 정보들을 패킷에 담아서 네이버 서버로 보냅니다. 서버는 받은 패킷 안에 있는 HTTP 요청 메시지를 해석합니다. 해석한 후에 서버에서 HTTP 응답 메시지를 생성해서 똑같이 패킷에 담아서 클라이언트로 보냅니다. 클라이언트는 HTTP 응답 메시지를 보면 html 코드가 있기 때문에 웹 브라우저에 렌더링되어 화면에 보여지게 됩니다.
HTTP 요청 메시지
GET /search?name=minsu&lan;=ko HTTP/1.1 Host: www.naver.com
HTTP 응답 메시지
HTTP/1.1 200 OK Content-Type: text/html;charset=UTF-8 Content-Length: 3423 ...
HTTP
HTTP(HyperText Transfer Protocol)는 하이퍼 텍스트 문서 간에 연결할 수 있는 html을 전송하는 프로토콜입니다.
현재는 모든 것을 HTTP 프로토콜에 담아서 전송하게 됩니다. (html, text, json, xml, image, 음성, 영상 ...)
또한 HTTP 에도 버전이 있는데 가장 많이 사용하는 버전이 HTTP/1.1 이 있습니다. 따라서 HTTP/1.1 을 공부하는 것이 중요합니다.
TCP는 HTTP/1.1, HTTP/2 를 사용하고,
UDP는 HTTP/3 를 사용합니다.
HTTP 특징
클라이언트 - 서버 구조 클라이언트가 서버에 요청을 하고, 서버는 요청에 대한 응답하는 구조
Stateless(무상태) Protocol, 비연결성
HTTP 메시지를 통해 통신
단순하고, 확장 가능
무상태 (Stateless)
위에서 HTTP는 Stateless Protocol의 특징을 갖는다고 했습니다.
Stateless란, 서버가 클라이언트의 상태를 보존하지 않는다는 뜻입니다.
반대가 Stateful은 서버가 클라이언트의 상태를 보존한다는 뜻입니다.
먼저 Stateful을 사용한다고 가정해봅시다.
Stateful은 상태를 유지한다고 했습니다. 이는 즉, 항상 같은 서버가 유지되어야 한다는 점입니다. 왜냐하면 클라이언트A가 서버1한테 요청을 한다면 그 요청에 대한 응답을 해줄 수 있는 서버가 딱 서버1밖에 없기 때문입니다. 이는 곧 단점이 됩니다.
만약 서버1이 장애가 나서 죽어버린다면 클라이언트A는 더 이상 요청을 할 수 없게 됩니다.
하지만 Stateless를 사용한다고 가정해봅시다.
Stateless는 상태를 유지하지 않습니다. 이는 즉, 아무 서버나 호출해도 상관없다는 뜻입니다. 왜냐하면 클라이언트A가 서버1한테 요청을 한다면 그 요청에 대한 응답은 꼭 서버1이 아니더라도 서버2한테 요청을 해도 똑같은 응답을 얻을 수 있습니다.
따라서 중간에 서버1이 장애가 나더라도 서버2를 사용하면 되기 때문에 정상적으로 요청에 대한 응답을 받을 수 있게 됩니다.
이러면 스케일 아웃이라고 해서 서버를 확장하는데 굉장히 유리합니다.
이렇게만 보면 Stateless는 장점만 있는 것 같지만 한계가 있습니다.
만약 로그인 기능이 있는 사이트가 있다고 가정해봅시다. Stateless를 사용한다면 로그인을 하고 상품상세 페이지로 이동시 다시 로그인을 해야 합니다. 상태를 보존하지 않기 때문이죠.
그래서 Stateless를 사용하면서 상태를 보존할 수 있는 방법이 바로 브라우저 쿠키나 서버 세션을 이용하면 상태를 유지할 수 있습니다.
Stateless의 또 다른 단점은 데이터를 많이 보냅니다.
다른 서버로 요청해도 똑같은 응답을 받을 수 있는 이유는 구체적인 데이터를 보내기 때문에 데이터를 더 많이 보낼 수 밖에 없습니다.
비연결성 (connectionless)
기본적으로 TCP/IP 통신을 하게 되면 클라이언트가 요청하고 서버가 응답하는 통신이 서로 연결되어 있습니다. 만약 여러 클라이언트가 한 서버에 계속 연결되어 있다면 서버 자원이 계속 소모된다는 단점이 있습니다.
반면에 비연결성을 사용하게된다면 클라이언트가 서버에 요청을 하고 나서 바로 연결을 끊어버립니다. 이러면 장점이 서버 자원의 소모를 막을 수 있습니다. 필요할 때마다 다시 연결을 하면 되니까요.
바로 HTTP는 기본적으로 비연결성의 모델을 사용합니다.
이러면 응답 속도도 굉장히 빠릅니다.
만약 연결성 모델을 사용한다고 가정하고 클라이언트가 수천, 수만명이라고 가정해보죠. 이러면 서버가 수천, 수만명의 자원 소모를 버틸 수 없게 됩니다.
따라서 비연결성을 사용하게 되면 수천, 수만명과 통신을 해도 요청-응답하고 바로 연결을 끊기 때문에 서버가 버틸 수 있게 됩니다.
하지만 비연결성에도 한계점이 있습니다.
검색창에 검색을 하면 처음에 TCP/IP 연결을 새로 맺습니다. 하지만 검색하고 나서 다른 페이지 이동 요청을 하게 되면 다시 TCP/IP 연결을 또 새로 맺어야 합니다. 앞서 TCP/IP는 3 way handshake 과정을 거치는데 이러면 시간이 계속 추가가 됩니다.
또 다른 한계점은 웹 브라우저 요청을 하게 되면 html, js, css, image 등등 수많은 자원이 함께 다운로드되서 매 요청마다 자원 소모가 됩니다.
그래서 지금은 HTTP의 이러한 한계점들을 지속 연결로 문제를 해결합니다. 그 밖에 HTTP/2, HTTP/3 에서 최적화가 많이 되었습니다.
HTTP 메시지
(HTTP 메시지 구조)
시작 라인
HTTP 버전, HTTP 메소드(GET, POST ...)
HTTP 상태 코드
헤더
HTTP 전송에 필요한 모든 부가정보 (메타 데이터) 메시지 바디의 내용, 크기, 요청 정보, 인증, 캐시 등등...
Content-Type, charset, Content-Length 등의 정보를 담습니다.
메시지 바디
from http://azurealstn.tistory.com/113 by ccl(A) rewrite - 2021-12-01 18:26:34