HTTP, TCP, UDP

HTTP(Hyper Text Transfer Protocol)란?

인터넷을 통해 웹 브라우저와 웹 서버 간에 텍스트, 이미지, 사운드, 비디오 및 멀티미디어와 같은 정보를 인코딩하고 전송하기 위한 프로토콜이다

HTTP의 특징

• HTTP는 상태를 유지하지 않는 프로토콜(Stateless)
• HTTP은 독자적으로 request와 response를 교환하는 동안의 상태를 관리하지 않는다.
• 이전에 보냈던 requset, 이미 돌려준 reponse에 대해서도 전혀 관리되지 않는다.
• HTTP에서는 새로운 request가 보내질 때 마다 새로운 response가 생성된다.

• 장점 : 많은 data를 매우 빠르고 확실하게 처리하기 위해 간단하게 설계됨
• 단점: 특정 사이트 로그인시 다른 페이지를 이동해도 그 로그인 상태를 유지할 수 없다.
  -> 쿠키 도입

쿠키(Cookie)

쿠키는 인터넷을 사용하는 유저가 어떤 웹사이트를 방문했을 때 그 사이트가 사용하는 서버를 통해 로컬에 저장되는 작은 데이터이다.

쿠키는 간단한 사용자의 정보를 기억할 수 있는 수단이며 이것은 HTTP의 단점을 해결하게 된다.

단 쿠키는 사용자 인증, 검색 기록 등의 개인 정보를 저장하는 것이기 때문에 사용자의 개인 정보를 침해 당할 소지가 있다.

그러므로 쿠키에는 중요한 정보를 담는 것은 위험하고 웹사이트는 반드시 쿠키를 저장해도 되는지의 여부를 사용자에게 물어봐야 한다.

지금은 modern storage APIs(localStorage/sessionStorage)를 사용해 정보를 저장하는 걸 권장한다.
모든 요청마다 쿠키가 함께 전송되기 때문에 성능이 떨어지는 원인이 될 수 있기 때문이다.

HTTP의 동작 방식

클라이언트(웹 브라우저, 모바일 등)가 브라우저를 통해서 어떠한 서비스를 URI를 통해 서버에 요청(Request)하면 서버에서는 해당 요청에 대한 결과를 응답(Response)하는 형태로 동작한다.

HTTP 요청 메서드

Get 메소드: 리소스 획득 (정보를 달라고 함)

• Get 메소드는 리퀘스트 URI로 식별된 리소스를 가져올 수 있도록 요구한다.
• URI에 이어 붙이기 때문에 길이 제한이 있다. 그래서 많은 양의 데이터는 보내기 어렵다.
• 가져올 리소스 내용은 지정된 리소스를 서버가 해석한 결과로, 텍스트이면 그대로 반환, 프로그램이면 실행해서 출력된 내용을 돌려준다.
• 성공 시 status code가 200 OK
• get은 길이 제한이 있어서 10MB를 보내고 싶어도 limit이 있어서 온전히 보낼 수 없고 잘라서 보내야 된다.

Post 메소드: 엔티티 전송 (정보를 알려줌)

• Post 메소드는 엔티티를 전송하기 위해서 사용된다.
• 대용량 데이터를 전송 -> 전송해야할 데이터를 HTTP의 Body에 길이 제한 없이 데이터를 전송
• 성공시 status code가 201 created
• body로 보냈을때의 장점 은닉화(캡슐화), format의 제한이 없다(text,json), 사이즈 제한이 없다.

GET 메소드 VS POST 메소드

• GET 메소드 : 주로 조회 할 때 사용한다. (게시글 조회, 웹페이지 조회)
• GET으로 서버에게 동일한 요청을 여러 번 전송하더라도 동일한 응답이 돌아와야 한다.

• POST 메소드 : 서버상태나 데이터 변경시 사용 (게시글 쓰기, 삭제 : 서버의 무언가가 변경)
• POST로 서버에게 동일한 요청을 여러 번 전송해도 응답은 항상 다를 수 있다.

PUT
리스소를 업데이트 하는데 사용되며 자원 전체를 갱신한다.

PATCH
리소스를 부분 업데이트를 하는데 사용된다. 해당 자원의 일부만 갱신한다.

DELETE
특정 리소스를 제거하는 데 사용한다.

HEAD
GET이랑 유사하지만 응답 Body가 없다.

OPTIONS
지원되는 메소드 종류를 파악할 때 사용한다.

HTTP 약점

• 평문(암호화 하지 않은) 통신이기 때문에 도청 가능
• 통신 상대를 확인하지 않기 때문에 위장 가능
• 완전성을 증명할 수 없 기 때문에 변조 가능

즉 HTTP는 평문(암호화되지 않은 정보)으로 통신을 하기 때문에 보안이 취약한 프로토콜이다.
그래서 나온 것이 HTTPS이다.

HTTPS

Hypertext Transfer Protocol Over Secure Socket Layer.
HTTP는 원래 TCP 와 직접 통신했지만,

HTTPS에서 HTTP 는 SSL과 통신하고 SSL이 TCP 와 통신한다.
SSL을 사용한 HTTPS는 암호화와 증명서, 안전성 보호를 이용할 수 있게 된다.

항상 HTTPS를 사용하지 않는 이유

• 메모리/CPU 리소스가 많이 필요하기 때문에 민감한 정보가 없을 경우 HTTP를 사용 (특히 액세스가 많은 웹사이트의 경우 부하가 상당하다)
• 증명서 구입 비용 : CA에서 증명서를 구입시 비용 지불을 해야하기 때문

IP 프로토콜

IP 프로토콜은 택배랑 같다. 클라이언트에서 보낸 데이터가 서버로 도착하고, 서버는 잘 받았다고 클라이언트에게 메시지를 보낸다.
하지만, IP 프로토콜에는 단점이 존재한다.

• 비 연결성
  : 서버의 상황을 클라이언트가 알 방법이 없다. 받을 상대가 없고 서비스가 불능이어도 데이터를 보낸다.
• 비 신뢰성
  : 패킷이 전송되다가 중간에 손상되거나 순서가 바뀌어도 클라이언트는 알 수 없다.
• 프로그램 구분 불가능
  : 같은 IP를 사용하는 애플리케이션이 여러 개일 때, 어떤 애플리케이션 클라이언트가 데이터를 보낸 건지 알 수가 없다.
  이런 IP 프로토콜의 단점을 보완한 것이 TCP 이다.

TCP

TCP는 장치들 사이에 논리적인 접속을 성립하기 위하여 3 way handshake를 사용하는 연결 지향형 프로토콜이다.

또한 TCP는 데이터 전송이 성공적으로 이루어진다면 이에 대한 응답을 돌려주기 때문에 IP 패킷의 한계인 비연결성을 보완할 수 있다.

만약 패킷이 순서대로 도착하지 않는다면 TCP 세그먼트에 있는 정보를 토대로 다시 패킷 전송을 요청함으로써 IP 패킷의 한계인 비신뢰성(순서를 보장하지 않음)을 보완할 수 있다.

1. 클라이언트가 먼저 서버 컴퓨터로 SYN 패킷이라는 연결 요청 메시지를 보낸다.

2. 이를 전달받은 서버 컴퓨터가 ACK 패킷을 보낸다.
   이는 Acknowledgment 의 약어로 연결 요청을 승인한다는 의미이며, 이 때 SYN 패킷도 함께 보낸다.

3. 서버 컴퓨터로부터 SYN ACK 을 전달받은 클라이언트 컴퓨터는 다시 ACK 패킷을 서버 컴퓨터에게 전송한다.

이 때, 데이터를 함께 보낼 수 있으며 지금부터는 정상적인 연결이 완료되어 데이터가 교환될 수 있다.

연결을 끊을 땐 4 way Handshake 과정을 거친다.

UDP (User Datagram Protocol)

비연결을 지향하며 신뢰할 수 없는 통신을 제공한다.

서버와 클라이언트끼리 연결되지 않은 상태이다.

UDP는 데이터 전달에 대한 보증과 데이터의 순서도 보장해주지 않는다.

그래서 신뢰하지 않는 정보를 보낼 때 빠른 속도를 가진 UDP를 주로 쓴다.
// 우체통으로 보내는 편지라고 생각