HTTP #0 인터넷 네트워크

함형주·2022년 11월 1일
0

HTTP

목록 보기
1/5

질문, 피드백 등 모든 댓글 환영합니다.

HTTP는 인터넷 위에서 작동하므로 먼저 인터넷 네트워크에 대해 정리하겠습니다.

IP(Internet Protocol)

인터넷 통신을 할 때 기본적으로 IP를 사용합니다.

IP는 복잡한 인터넷 망에서 주소의 역할을 합니다.

IP는 Octet(8bit, 1byte) 4개로 조합된 32bit로 구성됩니다. IP는 실제로는 2진수로 사용하지만 사람이 알아보기 쉽도록 10진수로 나타내는 dot-decimal notice 표기법을 주로 사용합니다.
ex) 000.000.000.000

IP를 통해 서버와 클라이언트를 구분하고 Packet이라는 통신 단위를 사용하여 데이터를 전달합니다.

Packet은 데이터가 전달되는 기본 단위로 통상적으로 헤더 + 페이로드(내용/데이터) + 트레일러로 구성됩니다.

일반적으로 Packet의 헤더에 주요 제어 정보(클라이언트 IP, 서버 IP 등)를 포함하고 트레일러에는, 패킷 에러 검출 등에 사용할 정보를 포함합니다. (트레일러가 없는 경우도 많습니다.)

IP 한계

  • 비연결성 : IP Packet은 대상 서버가 존재하지 않거나 받을 수 없는 상황이어도 전송됩니다. 즉 데이터를 보낼 때 대상 서버가 Packet을 받을 수 있는 상황인지 알 수 없습니다.

  • 비신뢰성 : 데이터 전송 도중 Packet이 소멸되거나 전송한 Packet이 순서대로 도착하지 않을 수 있습니다. Packet의 크기가 크면 분할해서 보내는데 이 때 이런 문제가 발생할 수 있습니다.

  • 같은 IP에서 실행되는 애플리케이션이 여러 개 일 수 있으므로 IP 만으론 이를 구분할 수 없습니다.

IP만으로는 명확한 한계를 가지기에 다른 프로토콜들과 함께 사용합니다.

인터넷 프로토콜 스택 계층

  1. 애플리케이션 계층 : HTTP, FTP // 브라우저, 프로그램, SOCKET라이브러리
  2. 전송 계층 : TCP, UDP // OS 계층
  3. 인터넷 계층 : IP // OS 계층
  4. 내트워크 인터페이스 계층 (최하단) // LAN 드라이버, LAN 장비
  • 애플리케이션이 메시지 생성 -> SOCKET 라이브러리를 통해 전달 -> TCP, UDP 정보 생성
    -> IP Packet 생성

즉 IP Packet은 TCP와 UDP 데이터를 포함합니다.

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

TCP는 3 way handshake를 이용하여 연결을 보장합니다.

  • 연결 지향 : TCP는 3 way handshake를 이용하여 연결을 보장합니다. SYN(접속 요청), ACK(요청 수락)을 통한 3번의 클라이언트와 서버가 연결되었음을 인지하고

      1. client to server : SYN (데이터 받을 수 있는지 확인)
      1. server to client : SYN + ACK (받을 수 있음 + 데이터 보내라고 명령)
      1. client to server : ACK (확인 응답)
      1. 데이터 전송 (요즘은 최적화가 잘 되어서 3 단계에서 데이터를 보내기도 함)
  • 순서 보장 : TCP는 순서 정보를 포함하여 만약 1, 2, 3 순서의 Packet이 1, 3, 2순서로 도착했다면 서버에서 2번 Packet부터 다시 요청하여 순서를 보장합니다.

  • 데이터 전달 보증 : TCP를 사용한 통신에서는 데이터가 잘 전송되었다면 서버에서 데이터 전송에 대한 확인 응답을 내려 데이터의 전달을 보증합니다.

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

UDP는 자체적인 기능이 거의 없어 TCP 처럼 데이터의 전달과 순서가 보장하지는 않으나 구조가 단순하고 성능이 빠릅니다. 사실상 신뢰성이 없기에 데이터 전송 시 일정량의 데이터가 누락이 될 수도 있는 프로토콜입니다. Port와 checksum 등을 포함합니다.

그럼에도 UDP를 사용하는 이유는 온라인 게임 등 실시간 서비스를 하는 애플리케이션에선 TCP가 너무 비효율적이었기 때문입니다. 당장 게임을 해야 하는데 중간에 데이터가 일부 소실되었다고 게임이 중단되는 일이 발생한다면... 때문에 실시간성 보장이 중요한 게임, 스트리밍 분야 등에서 주로 사용하고 무결성이 중요한 부분은 TCP를 사용합니다.
(사실 애플리케이션 레벨에서 TCP 기능 로직을 직접 다룬다면 UDP를 사용하더라도 신뢰성 등을 보장할 수 있긴 합니다.)

  • PORT : 하나의 IP에서 여러 개의 애플리케이션이 동작할 때 이를 구분합니다.
    0 ~ 65535 까지 할당 가능
    0 ~ 1023 : 잘 알려진 포트로 되도록 사용하지 않음

  • 체크섬 : 전달된 데이터를 검증합니다.

DNS (Domain Name System) 도메인 네임 시스템

IP는 기억하기 어렵고 무엇보다 변경될 수 있기에 DNS를 도입하여 사용합니다.
DNS는 IP 주소를 도메인 이름으로 관리하는 일종의 전화번호부입니다.

Domain nameIP
google.com000.000.000.000
......

URI (Uniform Resource Identifier)

URI는 특정 리소스를 식별하는 통합 자원 식별자로 서버에서 사용하는 논리적 또는 물리적 리소스를 식별하는 고유한 문자열 시퀀스입니다.

URI는 locator(URL), name(URN)으로 분류됩니다.
URL은 리소스의 위치를 의미하며 URN은 리소스에 이름을 부여합니다.

URI의 문법은 scheme://[userinfo@]host[:port][/path][?query][#fargment] 입니다.
userinfo@는 잘 사용하지 않고 :port는 생략 가능, #fragment는 html 내부 북마크 등에 사용되므로 서버에 전송되는 정보는 아닙니다.

https://velog.io/@gudwn357?tag=http 를 예로 들면

https : scheme (프로토콜)
velog.io : host (호스트 명) 도메인 명 또는 IP 주소를 직접 사용 가능
@gudwn357 : path, 리소스 경로
tag=http : query(쿼리 파라미터) key=value 형태의 파라미터, &로 여러 파라미터 사용

URN만으로 실제 리소스를 찾는 방법이 보편화 되지 않아 거의 언급되진 않습니다.

때문에 URI와 URL을 같은 의미로 사용하는 경우가 많은데 실제로 그 의미도 비슷합니다. 하지만 URL은 URI에 포함되는 개념이고 분명히 차이점이 존재합니다.

URI vs URL

Identifier와 Locator의 차이를 생각해봐야 합니다.

https://velog.io/@gudwn357 을 예로 들겠습니다.

위의 주소로 접속하면 velog.id 도메인으로 연결되어 @gudwn357 회원의 블로그
정보를 요청합니다. @gudwn357은 회원을 식별하는 의미를 가지므로 URI 입니다. 하지만 @gudwn357 자체가 회원 리소스의 위치를 의미하지는 않으므로 URL은 될 수 없습니다.

만약 https://hhj.com/webapp/index.html이 있다면 어떨까요?
index.html은 실제 서버의 html 리소스 경로를 의미하므로 URI와 URL 둘 다 해당됩니다.

profile
평범한 대학생의 공부 일기?

0개의 댓글