시작이 반이다.

HTTP 메서드(Method)

GET

리소스(representation) 조회
- 서버에 전달 할 데이터는 query(쿼리 파라미터,스트링)를 통해서 전달한다.
- 메시지 바디를 사용해서 전달할 수 있지만 지원하는 곳이 많지 않아 권장하지 않음

- 주로 검색 필터로 많이 활용한다.

POST

요청데이터 처리 및 등록

- 대상 리소스가 고유한 의미 체계에 따라 요청에 포함된 표현을 처리하도록 요청한다. 라는 스펙이다.

- 메시지 바디를 통해 요청 데이터를 전달하며, 주로 신규 리소스 등록, 프로세스 처리에 사용한다.

-리소스만으로 설계가 안되는 경우 컨트롤 URI를 사용한다
  ex) /orders/{orderId}/start-deliver

- 다른 메서드로 처리하기 애매한 경우에도 POST를 사용한다.

- JSON 조회 데이터를 넘겨야 하는데 GET 메서드를 사용하기 어려운 경우에도 POST 사용

PUT

리소스를 대체(replace), 해당 리소스가 없으면 생성
- 리소스를 완전히 대체하는 개념이다.

- 클라이언트가 리소스의 위치를 알고 URI를 지정한다.

DELETE

리소스 삭제

그 외 메서드

• HEAD :GET과 동일하지만 상태 줄과 헤더만 반환
• OPTIONS : CORS에서 주로 사용
• CONNECT: 대상 리소스로 식별되는 서버에 대한 터널을 설정
• TRACE: 대상 리소스에 대한 경로를 따라 메시지 루프백 테스트를 수행

HTTP 메서드의 속성

HTTP 메서드들은 다음과 같은 속성을 가지고 있다.

여기서 눈여겨 봐야할 것이 안전, 멱등, 캐시 가능 여부이다.

안전(safe)

호출해도 리소스를 변경하지 않는다는 속성이다. 안전은 해당 리소스에만 해당된다.

멱등(Idempotent)

단어를 어디선가 들어본 것도 같고, 되게 낮선 단어같기도 하다.
멱등은 어떤 작업, 함수, 또는 연산을 여러 번 적용하더라도 결과가 바뀌지 않는 성질을 나타낸다.

수학적으로 표시하면 f(f(x)) = f(x)를 만족하는 함수를 나타낸다.

즉, HTTP 메서드 속성에서의 멱등의 의미는 한 번을 호출하든 여러번 호출하든 결과가 똑같음을 의미한다.

위의 그림을 보면 GET,PUT,DELETE는 멱등한 메서드이다.

몇 번을 조회(GET)하든 결과는 같다.

PUT과 POST의 차이는 위에서 PUT은 클라이언트가 URI를 알고 지정한다고 했다.

PUT은 URI를 지정하고 같은 바디를 같은 요청으로 계속 보내기 때문에 결과가 같을 수 밖에 없다.

POST는 요청을 클라이언트에서 지정하지 않고 서버 내부에서 처리하기 때문에 서버 내부에서 처리하는 로직에 따라 결과가 다를 수 있다.
삭제(DELETE) 또한 같은 요청을 계속하더라도 결과는 같다.

만약에 여러번 조회(GET)중에 중간에 다른 곳에서 PUT을 날려서 재요청 도중에 데이터를 바꾼다면 어떻게 될까?

그렇게 된다면 처음 조회와 재요청 조회의 결과가 달라질 것이다.
하지만 멱등은 외부 요인으로 리소스가 바뀐 것까지는 고려하지 않는다.

멱등은 주로 자동 복구 메커니즘이나 서버가 Timeout으로 응답을 못주었을때,

클라이언트가 같은 요청을 다시해도 되는 가?에 대한 판단 근거로 사용된다.

캐시 가능(Cacheable)

응답 결과 리소스를 캐시해서 사용해도 되는 가의 여부를 판단하는 속성이다.

위의 그림을 보면 GET,HEAD,POST,PATCH가 캐시 가능하다.

실제로는 GET,HEAD 정도만 쓰인다.
POST와 PATCH는 본문 내용까지 캐시 키로 고려해야 하는데, 그 부분이 쉽지 않아 잘 쓰이지 않는다.

참조(Reference)

https://www.inflearn.com/course/http-%EC%9B%B9-%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC/dashboard

2023.08.28 - [Computer Science/Network] - HTTP와 HTTPS

해당 글에서 HTTP에 대해서 알아보았다. 이번에는 HTTP가 가지고 있는 특징과 메서드 위주로 알아보려고 한다.

HTTP의 특징

모든 것이 HTTP라고 해도 과언이 아닐 정도로 HTTP에 모든 것을 전송할 수 있다.

• HTML, TEXT
• IMAGE, 음성, 영상, 파일
• Json, XML (API)
• 서버 간 데이터 전송

HTTP의 특징들은 다음과 같다.

• 클라이언트 서버 구조
  
  • Request Response 구조
  • 클라이언트는 서버에 요청하고, 응답을 대기한다
  • 서버가 결과를 만들어서 응답한다.
• 무상태 프로토콜(Stateless)
  • 서버가 프로토콜 상태를 보존하지 않음
  • 서버 확장성이 높음
  • 클라이언트가 데이터를 추가로 전송해야 한다는 단점이 있음
• 비연결성
  • HTTP는 기본이 연결을 유지하지 않음
  • 초단이 이하의 빠른 응답, 효율적인 서버 자원 사용
  • 하지만 TCP/IP는 연결하기 위해서 매번 3 way Handshake 과정을 거쳐야 한다.
    이러한 문제를 HTTP 지속 연결(Persistent Connections)을 통해 해결하였다.
  • HTTP/2와 HTTP/3에서는 더 개선되었다.
• 단순함, 확장 가능
• HTTP 메시지
  • HTTP 요청 메시지
  • HTTP 응답 메시지

HTTP 요청(Request) 메시지

HTTP 요청 메시지의 시작 라인은 다음과 같이 나뉜다.

• HTTP 메서드
  • GET : 리소스 조회
  • POST : 요청 내역 처리
  • PUT : 리소스 업데이트 또는 새로 생성
  • DELETE : 리소스 삭제
• 요청 대상 : 절대 경로[?쿼리]의 형식
• HTTP 버전 : HTTP/1.1 , HTTP/2

HTTP 응답(Response) 메시지

HTTP 응답 메시지의 시작 라인은 다음과 같다.

• HTTP 버전 : HTTP/1.1 , HTTP/2
• HTTP 상태 코드 : 요청 성공, 실패를 나타내며 주로 2xx,4xx, 5xx를 자주 쓴다. 
• 이유 문구 : 사람이 이해할 수 있는 상태 코드의 짧은 설명 글

그리고 HTTP 헤더와 HTTP 메시지 바디로 나뉜다.

• HTTP Header : HTTP 전송에 필요한 모든 부가 정보
• HTTP Message Body : 실제 전송할 데이터 ( HTML 문서, 이미지, 영상, JSON 등) 

HTTP 메서드, 헤더, 상태 코드에 관한 자세한 내용은 다음 글에서 다루도록 하겠다.

참조(Reference)

https://www.inflearn.com/course/http-%EC%9B%B9-%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC/dashboard

URL, URI, URN이라는 단어중 하나는 들어봤을 것이다. 아마 URN은 못들어봤을 수도 있다.

이 단어들에는 어떤 차이가 있을까?

URI? URL? URN?

URI(Uniform Resource Identifier)는 인터넷 상에서 리소스를 고유하게 식별하기 위한 텍스트 문자열이다.

더 자세히 알아보자면,

U는 Uniform의 약자로, 리소스를 식별하는 통일된 방식을 말한다.

R은 Resource의 약자로, 자원, URI로 식별할 수 있는 모든 것을 말한다.

I는 Identifier의 약자로, 다른 항목과 구분하는 데 필요한 정보를 말한다.

URI는 로케이터(Locator)와 이름(Name) 또는 둘 다로 분류될 수 있다.
그렇다면 로케이터(Locator)와 이름(Name)는 무엇일까?
바로 URL(Uniform Resource Locator)와 URN(Uniform Resource Name)이다.

즉 다음과 같이 표현할 수 있다.

URI에 대한 자세한 형태는 다음과 같다.

• scheme : 리소스에 접근하는데 사용하는 통신 프로토콜을 입력하는 부분 (http,https)
• authority 
  • host : 리소스가 호스팅되어 있는 서버의 주소를 입력하는 부분으로 도메인명, 호스트명, ip주소로 입력 가능하다.
  • port : 포트는 일반적으로 http는 80번, https는 443을 사용하며 생략이 가능하다.
• path : 웹 서버 내 리소스의 경로를 나타내는 부분으로, 계층적 구조를 가지고 있다. ( /로 계층을 구분한다.)
• query : 웹서버로 전달되는 추가적인 정보를 나타내는 부분으로 key=value 형태로 이루어져있다.
                ?로 시작하며 &로 연결한다. 주로 쿼리스트링 또는 쿼리 파마리터라고 부른다.(문자열로 전달되기 떄문) 
• fragment : 웹 페이지 내에서 특정 부분을 가르키기 위한 부분으로, html 내부 북마크 등에 사용한다.

URL의 경우는 리소스가 있는 위치를 지정하며, URN의 경우 리소스에 이름을 부여한다.
URN은 이름만 가지고 리소스를 찾는 방법이 보편화되지 않아서 URN을 잘 쓰지는 않는다고 한다.

웹 브라우저의 요청 흐름

실제로 브라우저에 요청을 하면 어떤식으로 흐름이 흘러가는 걸까?
구글에 hello라는 단어를 검색한다고 가정해보자.

다음과 같이 요청한다면, DNS(도메인 네임 서버)에서는 실제 구글 서버의 ip를 알려줄 것이다.
클라이언트는 다음과 같은 http 요청 메시지를 서버로 전송할 것이다.

http 요청 메시지는 다음과 같이 서버에 전달될 것이다.

서버에서는 요청 패킷이 도착하면 HTTP 응답 메시지를 생성하여 클라이언트에게 전달할 것이다.

응답 패킷이 클라이언트에게 전달되면, 해당 응답 메시지로 웹 브라우저 HTML을 렌더링하는 것이다.

참조(Reference)

https://www.inflearn.com/course/http-%EC%9B%B9-%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC/dashboard

인터넷에서 컴퓨터 둘은 어떻게 통신할까?

복잡한 인터넷 망에서 클라이언트와 서버는 어떻게 통신하는 걸까?

이를 이해하기 위해서는 IP(인터넷 프로토콜)에 대해 알아야 한다.

IP(인터넷 프로토콜)의 역할

• 지정한 IP 주소(IP Address)에 데이터 전달
• 패킷(Packet)이라는 통신 단위로 데이터 전달

IP 패킷은 전송 데이터, 출발지 IP, 목적지 IP, 기타 정보 등을 담고 있다.

클라이언트와 서버는 각각 출발지 IP와 목적지 IP에 패킷을 전송하면서 통신한다.

하지만 IP 프로토콜에는 많은 단점과 한계점이 존재한다.

IP 프로토콜의 한계

• 비연결성
  - 대상 서버가 패킷을 받을 수 있는 상태인지 알 수 없다.
  - 패킷을 받을 대상이 없거나 서비스 불능 상태여도 패킷을 전송한다.
• 비신뢰성
  - 중간에 패킷이 사라져서 손실이 발생할 수 있다.
  - 패킷이 순서대로 오지 않을 수 있다.
• 프로그램 구분
  - 같은 IP를 사용하는 서버에서 통신하는 애플리케이션이 둘 이상이라면?
     IP만으로는 어떤 애플리케이션에 요청을 한 건지 전혀 알 수 없다는 문제가 발생한다.

이러한 문제점을 해결해 줄 수 있는 게 바로 전송 제어 프로토콜(TCP; Transmission Control Protocol)이다.

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

인터넷 프로토콜 스택 4 계층이란 인터넷에서 컴퓨터들이 서로 정보를 주고받는 데 쓰이는 프로토콜의 모음이다.

용도에 따라 4개의 계층으로 나뉘어있다.

애플리케이션 계층은 프로그램 간 통신을 위한 계층이다.

전송 계층은 송신자와 수신자를 연결하는 서비스에 대한 정보를 담는 계층이다.

인터넷 계층은 패킷을 목적지로 전송하기 위한 정보를 담는 계층이다.

네트워크 인터페이스 계층은 LAN 드라이버, LAN 장비 등 물리적 전송을 위한 계층이다.

실제 통신 예시는 다음과 같은 과정이 이루어진다.

TCP는 데이터를 세그먼트 단위로 나눠서 전송한다. 세그먼트는 패킷의 일부로서 데이터를 포함하며, TCP 헤더와 함께 전송된다.

MSS (Maximum Segment Size): TCP는 MSS라는 최대 세그먼트 크기를 사용하여 데이터를 나눈다.
이는 통신하는 양쪽의 호스트 간에 협상되며, 일반적으로 MTU (Maximum Transmission Unit) 크기에 맞추어 설정된다.

패킷 분할 (Packet Fragmentation): TCP는 패킷을 세그먼트로 나누어 전송하지만, 네트워크에서는 패킷 크기에 제한이 있을 수 있다.
이 경우, 패킷 분할이 발생할 수 있다. 라우터나 중간 장비에서 패킷이 네트워크 MTU보다 크다면, 패킷은 작은 조각으로 나눠져서 전송되며, 이를 패킷 분할이라고 한다.

TCP(전송 제어 프로토콜)의 특징

• 연결지향 - TCP 3 Way handshake (가상 연결)
• 데이터 전달 보증
• 순서 보장
• 신뢰성 있는 프로토콜

TCP는 다음과 같은 단계로 연결을 수행한다.

계속 연결되어 있는 상태는 아니고, 해당 연결 후 데이터를 받은 후에는 연결을 끊는다.

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

UDP는 TCP와 반대로 기능이 거의 없다. TCP처럼 연결 지향적이지도 않고, 데이터의 전달이나 순서도 보장할 수 없다.

그렇지만 단순하고 빠르다는 장점이 있다.

IP(인터넷 프로토콜)과 유사하지만 포트와 체크섬(checksum) 정도가 추가된다.

기존에는 실시간 비디오 스트리밍이나 사용자가 직접 프로토콜을 제어하고자 할 때 많이 사용했다.
요새는 스트리밍이더라도 TCP를 사용하는 경우도 많다고 한다.
참고로 최근에 발표된 HTTP/3의 경우 UDP 기반의 QUIC 프로토콜을 사용한다.

PORT (포트)

포트는 같은 IP 내에서 프로세스를 구분하기 위한 역할을 한다. TCP와 UDP는 둘 다 포트를 사용하는 프로토콜이다.
각 포트는 번호로 구별되며, 이를 포트 번호라고 한다. 포트 번호 중에서 자주 쓰이는 포트를 well-known Port라고 한다.

포트 번호는 0 ~ 65535까지 할당 가능하며, 0 ~ 1023 포트 번호는 위에서 말한 well-known Port에 해당하여 사용하지 않는 편이 좋다.

대표적인 well-known port는 다음과 같다.

• 20,21 - FTP
• 23 - TELNET
• 22 - SSH
• HTTP - 80
• HTTPS - 443

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

우리는 클라이언트와 서버가 IP를 통해서 인터넷 망에서 통신한다고 배웠다.
하지만 IP는 너무 기억하기 어렵다는 단점이 있다. 또한 IP는 고정이 아니다 바뀔 수 있다.

이러한 문제점을 해결해 줄 수 있는 게 도메인 네임 시스템(DNS)이다.

DNS는 도메인 명을 IP 주소로 변환한다.

예를 들어 우리가 구글에 접속한다면 다음과 같은 과정이 이루어진다.

1. 클라이언트는 구글의 도메인명을 브라우저에 입력한다.

2. DNS 서버에서 구글의 도메인 명에 대한 서버의 실제 IP 주소로 변환해 준다.

3. 클라이언트는 서버 IP 주소로 통신한다.

DNS를 사용하면 위에서 말한 IP의 단점인 기억하기 어려운 점과 IP가 유동적으로 바뀌는 문제를 해결할 수 있다.

Reference 

https://www.inflearn.com/course/http-%EC%9B%B9-%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC/dashboard