[HTTP] HTTP 기본 개념 정리

이 글은 백엔드 개발자를 위해 필수적인 HTTP 개념을 정리한 포스트입니다. 김영한 님의 김영한 모든 개발자를 위한 HTTP 웹 기본 지식 강의를 바탕으로 하되, 제 개인적인 해헉을 덧붙였습니다.

벡엔드 개발자가 왜(why) HTTP에 대해 알아야 할까?

대부분의 웹 애플리케이션은 HTTP 프로토콜을 기반으로 동작한다.

HTTP는 요청과 응답을 위한 상태 코드를 제공한다. 백엔드 개발자는 이러한 상태 코드를 이해하고 처리해야 한다.

HTTP 요청과 응답은 웹 애플리케이션의 성능에 큰 영향을 끼친다. 백엔드 개발자는 HTTP 헤더, 캐싱, 압축 등을 이해하여 웹 애플리케이션의 성능을 최적화할 수 있다.

이 밖에도 여러 이유들이 있다.

때문에 벡엔드 개발자를 희망한다면 HTTP에 대해 알아두는게 필수 라고 볼 수 있다.

이제 HTTP에 대해 알아보도록 하자

인터넷 네트워크

왜? 인터넷 네트워크에 대해 알아느냐

→ Web과 HTTP 둘 다 인터넷을 기반으로 동작하기 때문에 간략하게라도 알아둬야 한다.

학교에서 배운 컴퓨터 네트워크 내용도 중간중간 나오니 상세하게 알고싶다면 깃허브 블로그에 방문하여 확인하면 된다 :)

인터넷에서 컴퓨터가 통신하는 동작 순서

클라이언트와 서버가 바로 옆에 있다면 케이블로 연결해서 서로 주고 받으면 된다.

하지만, 대다수의 경우에는 클라이언트와 서버는 멀리 떨어져 있어서 인터넷을 사용하게 된다.

이 인터넷은 노드를 통해 서버로 넘어가게 된다.

하지만 단순하게 노드를 통해 서버로 넘어간다 라고 생각하면 안되는것이 다양한 상황이 주어지기 때문이다.

우리는 이 다양한 상황에 대해 알아보기 위해 IP 프로토콜에 대해 알아볼것이다.

IP(인터넷 프로토콜)

우선 클라이언트와 서버에 ip를 부여받는다.

이후 ip 주소로 데이터를 패킷이라는 단위로 전달하게 된다.

여기서 패킷을 보내는데는 규칙이 있다.

ip 패킷 정보는 아래와 같다.

• 출발지 IP
• 목적지 IP
• 전송 데이터
• 기타….

정보가 잘 들어갔으면 이제 클라이언트에서 패킷을 전송한다.

이후 노드를 통해서 서버로 전달되게 된다.

위 순서를 서버가 클라이언트에 요청을 했다 라고도 한다.

이후 서버에서 패킷을 잘 받았기 때문에 다시 클라이언트로 패킷을 전달할 수 있다.

이는 서버가 클라이언트에 응답했다 라고도 한다.

참고로 요청과 응답 과정에서 동일한 노드를 사용하지 않을 수 있다.

IP 프로토콜의 한계

• 비연결성
  • 패킷을 받을 대상이 없거나 서비스 불능 상태여도 패킷 전송
• 비신뢰성
  • 중간에 패킷이 사라지면?
  • 패킷이 순서대로 안오면?
• 프로그램 구분
  • 같은 IP를 사용하는 서버에서 통신하는 애플리케이션이 둘 이상이면?

비연결성

서버가 만약 죽어 있더라도 클라이언트에서 패킷을 전송한다.

하지만 노드를 통해 패킷이 서버에 도달해도 패킷은 결코 전달될 수 없다.

비신뢰성

클라이언트에서 패킷을 전달했으나 노드에서 패킷이 소실될 경우에도 전달될 수 없다.

소실되는 이유로는 매우 다양하다.

케이블을 야생 동물이 끊는다거나 하는 경우도 있다….

클라이언트에서 메세지를 보낼때 1500byte이상을 보낼 경우 한번에 보내기에 부담스럽기 때문에 끊어서 보낸다고 한다.

예를 들자면 위 Hello, World!를 보낼때 1500byte를 초과해서 “Hello,” “World!”로 나뉘어져서 보내진다.

이 메시지를 노드를 통해 보내는데 보내는 과정에서 동일한 노드로 전송되지 않을 수 있는데 이 과정에서 전송보낸 순서와 전달받은 순서가 바뀔 수 있다.

위와 같은 문제점들을 해결하는게 바로 TCP, UDP다.

TCP, UDP

인터넷 프로토콜 스택의 4계층

1. 애플리케이션 계층 - HTTP, FTP
2. 전송 계층 - TCP, UDP
3. 인터넷 계층 - IP
4. 네트워크 인터페이스 계층

유명한 계층이다.

프로토콜 계층

프로토콜 계층은 위와 같다.

만약 내가 외국에 사는 친구에게 채팅 프로그램을 통해 Hello라는 메시지를 보내면 위와 같이 동작한다.

계층이 달라질 때마다 정보들이 추가되는것을 확인 할 수 있다.

결국 이더넷 프레임 안에 TCP 정보가 있고 그 안에 IP 정보가 있고 그 안에 내가 보내는 메시지가 있는것이다.

• 이더넷 프레임의 용도는?
• 이더넷 프레임은 이더넷 네트워크에서 데이터를 전송하고 수신하는 데 사용되며, MAC 주소를 통해 출발지와 목적지를 식별

TCP의 구조

• 출발지 PORT
• 목적지 PORT
• 전송 제어
• 순서
• 검증 정보
• 전송 데이터
• 기타…

TCP 특징

전송 제어 프로토콜(Transmission Control Protocol)

• 연결지향 - TCP 3 way handshake (가상 연결)
  • 클라이언트와 서버가 연결이 되어있나 확인먼저 함
• 데이터 전달 보증
  • 패킷이 노드를 통해 소실이 되었는지 확인
• 순서 보장
  • 패킷을 나눠 보내더라도 순서대로 도착함
• 신뢰할 수 있는 프로토콜
• 현재는 대부분 TCP 사용

TCP 3 way handshake (연결 지향)

• SYN: 접속 요청
• ACK: 요청 수락

총 3번의 과정을 거친다.

1. ACK를 보낼때 데이터를 같이 보낼 수 있다.

참고로 물리적으로 연결된게 아니라 클라이언트와 서버가 연결이 되었다고 가상으로 확인한 것이다.

데이터 전달 보증

순서 보장

UDP 특징

사용자 데이터그램 프로토콜(User Datagram Protocol)

• 하얀 도화지에 비유(기능이 거의 없음)
• 연결지향 - TCP 3 way handshake X
• 데이터 전달 보증 X
• 순서 보장 X
• 데이터 전달 및 순서가 보장되지 않지만, 단순하고 빠름
• 정리
  • IP와 거의 같다. +PORT +체크섬 정도만 추가
  • TCP보다 빠르다.
  • 애플리케이션에서 추가 작업 필요

PORT

TCP의 구조에 PORT가 나왔었는데 이 PORT가 무엇일까?

우리는 지금까지 1ㄷ1 통신을 하고 있었다.

하지만 만약 위 그림과 같이 여러 서버와 통신해야 한다면 어떻게 해야할까?

IP를 통해 패킷이 넘어온다면, 동시에 여러가지를 하고 있다면 이게 게임에서 사용하는 패킷인지 웹 브라우저에서 사용하는 패킷인지 따로 구분할 수 없다.

이를 구분할 수 있게 해주는 역할이 바로 PORT다.

IP는 출발지와 목적지를 찾아주는 역할이고 PORT는 도착해서 어떤 역할인지 알려주는 셈이다.

같은 IP 내에서 PORT로 프로세스 구분

IP를 통해 출발하는곳과 도착하는곳을 알려주고, 도착한 후 PORT에 따라 패킷이 따라간다.

쉽게 말하자면 IP는 아파트, PORT는 동, 호수라고 생각하면 된다.

PORT

• 0 ~ 65535 할당 가능
• 0 ~ 1023: 잘 알려진 포트, 사용하지 않는 것이 좋음
  • FTP - 20, 21
  • TELNET - 23
  • HTTP - 80
  • HTTPS - 443

DNS

IP는 길기 때문에 기억하기가 어렵다.

또한, IP는 변경이 될 수 있다.

그럼 다시 상대에게 물어보거나 해야한다는 문제가 발생한다.

위와 같은 상황을 방지하기위해 DNS가 등장했다.

DNS는 전화번호부라고 생각하면 된다.

도메인 명을 IP 주소로 변환해주는 역할을 한다.

DNS 사용

위 그림처럼 전화번호부마냥 사용이 가능하다.

우리가 사용하는 naver.com도 알고보면 IP 주소로 연결해주는 역할을 하는 도메인이다.