HTTP 프로토콜 알고 쓰자!

안녕하세요!

오늘은 웹 개발 과정 중 자주 마주하는 HTTP 프로토콜에 대해 정리해보고 이해해보는 시간을 가지려고 해요. 흔히 이를 백엔드의 영역이라 생각하고 통신하는 경우가 많은데, 개인적으로 꼭 이해하고 넘어가야하는 개념이라 생각해서 정리해보고자합니다! 그럼 바로 시작하시죠~

HTTP란?

> Hyper Text Transfer Protocol

서버와 클라이언트간의 TCP/IP 통신 위에서 메시지를 교환하기 위해 사용되는 프로토콜입니다.

• 프로토콜

> ‘규약'이라는 뜻으로 서로 다른 하드웨어 기기가 통신하기 위한 규칙입니다.

프로토콜 규칙의 역할들에 따라 TCP/IP 4계층으로 분리해 생각해야 합니다.

클라이언트가 리소스를 HTTP를 통해 요청 >> TCP/IP 프로토콜을 걸쳐 서버 쪽의 HTTP까지 요청이 도달하게 되는데

이에 대한 응답을 다시 서버에서 HTTP로 보내면 TCP/IP 프로토콜을 통과해 클라이언트까지 응답이 도달하게 되는 거죠.

• TCP/IP

> 수 많은 네트워크 기기들이 인터넷으로 통신하는 데 있어 가장 기반이 되는 프로토콜

좀더 깊게 이해해보죠.

TCP ( Tansmission Control Protocol )

‘잘 들리냐'

트랜스포트 계층에서는 서버와 클라이언트 사이 통신 연결을 담당하게 되는데요. 특이사항으로는 TCP에서는 바이트 스트림 서비스를 제공한다는 것입니다.

• Byte Stream

데이터를 잘게 쪼갠 뒤 전송하는 서비스.

이때, 정확히 전송되었는지 확인하는 기술이 바로 익숙한 개념

‘ 3way handshaking 기법입니다. ’

요청이 잘 넘어가는 지 계속 물어보고 이를 확인한 이후 데이터를 전송하는 개념이죠. 이 때문에 TCP 프로토콜은 ‘신뢰성'을 담당한다고 이야기됩니다.

IP (Internet Protocol)

TCP에서 연결된 것을 확인했으니 데이터를 보내게 되는데 IP에서 이를 담당합니다. 즉 IP에서 분할된 데이터 패킷들을 보내게 되는 거죠.

Internet Protocol

데이터 패킷들을 보내게 된다고 했는데, 그럼 보내게 되는 주소를 어떻게 알 수 있을까요?

흔히 IP주소를 생각하기 쉽지만 IP주소를 사용하게 되면 많은 문제점이 발생하게 됩니다. 고유하지 않기 때문에 신뢰성이 떨어질 수 있기 때문이죠.

따라서 Mac주소를 사용하게 되는데요. 그렇다면 왜 패킷을 보내는 과정에서 IP를 사용하게 되는 것일까요?

바로 ‘방향성' 때문인데요. 이 과정에서 ARP라는 개념이 등장합니다.

ARP (Address Resolution Protocol)

주소를 찾아가는 프로토콜이라는 뜻의 ARP는 수신자의 IP 주소로 수소문하고 도착한 곳 기기의 MAC 주소를 조사하며 이를 통해 배송지의 루트를 찾아내게 되는 것이죠.

이때 중간에 경유하는 네트워크 기기들은 전체 배송지의 루트를 알 수 없습니다. ** ARP에서도 중간에 경유되는 네트워크 기기들이 데이터를 배송할 다음 기기 위치만 알면 된다는 것이죠.

다음으로 알아볼 개념은 DNS입니다.

DNS(Domain Name System)

• 도메인 이름 및 IP주소를 확인하는 기능을 제공
• 도메인 이름을 IP 주소로 변환하고 도메인 이름을 웹 브라우저에 입력할 때 최종 사용자를 어떤 서버에 연결할 것인지를 제어
• 이때 등장한 개념 URI / URL

URL ( Uniform Resource Locator )

• 웹페이지 상의 표시 주소.
• URL은 흔히 웹 주소라고도 하며, 컴퓨터 네트워크 상에서 리소스가 어디 있는지 알려주기 위한 규약이다. URI의 서브셋이다.

URI ( Uniform Resource Identifier )

• URL을 포괄한 개념, 리소르를 식별하는 식별자를 뜻함.
• URI는 특정 리소스를 식별하는 통합 자원 식별자(Uniform Resource Identifier)를 의미한다. 웹 기술에서 사용하는 논리적 또는 물리적 리소스를 식별하는 고유한 문자열 시퀀스다.

URL / URI

이제 다 왔습니다.

HTTP 프로토콜에서는 서버와 클라이언트 간의 통신이 일어나게 되는데요.
이 둘의 개념에 대해 알아보시죠.

Request ( 요청 ) : Client to Server

• 요청은 메서드, URI, 프로토콜 버전, 헤더, 바디로 구성되어 있습니다.

Response ( 응답 메세지 ) : Server to Client

• 응답은 프로토콜 버전, 상태코드, 상태코드 설명, 헤더, 바디로 구성되어 있습니다.

HTTP 프로토콜은 기본적으로 stateless 특성을 가지고 있습니다.

HTTP는 남기지 않는다. (상태유지가 되지 않는다)

HTTP 프로토콜에서는 과거 정보를 남기지 않고, 새로운 리퀘스트를 보낼 때 마다 새로운 리스폰스를 보내는 것이죠.

상태와 무관하니 확장이 쉽다는 점이 있지만, 상태가 필요한 경우는 어떻게 처리해야 할까요? 예를 들어, 장바구니에 담은 물건들을 나중에 결제할 때와 같은 경우에 말이죠.

이와 같이 상태를 유지해야하는 경우를 보완하고자 세션과 쿠키 같은 기술등을 함께 사용하여 이를 해결하곤 하는 것이죠.

또 새로운 특징으로는 지속 연결성이 있습니다. 전송하는 데이터가 점점 많아지면서 초기의 비지속 연결이 문제가 생기기 시작합니다. 클라이언트 측에선 퍼포먼스 적으로 문제가 되는 것이죠. 매번 TCP연결을 종료하면 자원 낭비가 아무래도 심해지겠죠..? 때문에 지속 연결을 통해 서버의 부하를 줄이고 통신 속도를 높이기 시작합니다.

HTTP 메서드

• 멱등성 (Idempotent)

수학이나 전산학에서 연산의 한 성질을 나타내는 것으로, 연산을 여러 번 적용하더라도 결과가 달라지지 않는 성질을 의미.

HTTP에서는 여러번 요청한 결과 서버의 상태가 항상 동일할 때를 의미합니다. 메서드 별로 Idempotent 성립 여부가 다르니 주의깊게 보도록 하죠.

• GET

특정한 리소스를 가져오도록 하는 메서드

여러번 실행해도 특정 리소스를 보내주는 것임으로 멱등성이 성립.

• PUT

리소스 수정 메서드

대상 리소스가 없다면 생성하고 있다면 리퀘스트의 본문대로 교체.

PUT은 멱등성이 보장

• PATCH

리소스 수정 메서드

리소스의 일부를 수정하는 데 사용되어지며,

PATCH는 멱등성이 보장될 수도 있지만 그렇지 않을 수도 있습니다.

rfc2616 스펙 상으로는 멱등성을 보장하지 않았지만, 복수의 PATCH 요청의 부작용을 고려하게 되면서 이를 막는 목적으로 멱등하게 처리해도 된다고 추가 기술되어 있습니다.

• POST

대상 리소스에게 리퀘스트 본문을 해당 리소스의 시멘틱에 따라 처리하도록 요청하는 메서드.

게시판, 블로그 같은 글 모음에 글 보내기, 서버에 새로운 리소스 생성하기 등에 사용하기 때문에 멱등성이 보장되긴 어려움.

• DELETE

리소스를 삭제하는 메서드

멱등성이 보장되어야 함으로, 마지막 게시글 지워달라는 요청과 같이 실행 결과가 계속 달라지게 사용되면 안되겠습니다.

그 외에도, GET 요청으로 응답 헤더만 가져오는 HEAD

해당 리소스의 통신 옵션을 알려 주는 OPTIONS 등이 있는데요. 필요에 따라 골라쓰되 규약은 반드시 지켜야 하겠습니다.

HTTP 상태 코드

모든 HTTP 응답코드는 3가지의 숫자로 정의됩니다.

첫번째 숫자를 기준으로 5개의 클래스로 나뉘게 되는데요.

이후의 두자리는 해당 클래스의 구체적 상태들에 할당된 코드인데요.

• 1XX

요청을 받았으며 해당 요청에 대한 프로세스를 진행중

요청처리가 끝나지 않은 경우에 응답으로 해당 status code 를 보낼 일은 거의 없기 때문에 보기 어려운 코드입니다.

• 2XX

200번대는 성공상태를 의미합니다.

200 OK : 서버가 요청을 제대로 처리했음을 의미

201 Created : 서버가 요청을 제대로 처리했고 또한 요청에 따른 새로운 리소스가 서버에 저장되었음을 의미

204 No Content : 서버가 요청을 제대로 처리 했지만, 요청에 따른 콘텐츠를 제공하지 않을 때 사용됩니다.

• 3XX

300번대는 요청에 대한 추가적인 처리/동작이 필요하다는 응답이 돌아올 때 발생

추가 처리가 필요한 경우

해당 처리를 할 수 있는 위치를 함께 알려줄 필요가 있습니다. ( redirection )

Redirect :

• 받은 데이터 패킷을다른 URL로 중계함을 뜻함

POST로 보내진 요청이 위치 이동 시 GET으로 치환 됨에 따라 300번 상태 코드들이 다르게 쓰이는 것이죠.

주의할 사항은 304번은 redirect되어지지 않습니다. (마지막 요청 이후 요청한 페이지는 변경되지 않았다는 상태 코드)

현업에선 주로 301 redirect를 많이 사용하는 것 같네요.

• 4XX

클라이언트의 요청이 잘못됐을 때

400 Bad Request : 서버가 요청의 구문을 인식하지 못했다는 뜻의 상태 코드
(브라우저의 경우는 해당 코드와 200 OK를 동일하게 취급한다고 합니다)

401 Unauthorized : 해당 요청을 들어주기 위해선 인증이 필요하다는 상태코드 (로그인과 같은)

잘못된 인증 정보로 요청하는 경우에도 발생 ( id,pw 잘못 입력과 같은 )

403 Forbidden : 클라이언트가 리소스에 대한 필요 권한을 가지고 있지 않다는 뜻 (권한이 없다는 뜻, 관리자와 같은)

404 Not found : 해당 페이지를 찾을 수 없는 경우

(요청을 거부하고 싶지만 이유가 비밀인 경우에도 주로 사용 )

• 5XX

서버 때문에 발생하는 오류

500 Internal Server Error : 서버에 오류가 발생하여 요청을 수행할 수 없을 때 사용

501 Not Implemented : 서버에 요청을 수행할 수 있는 기능이 없을 때 사용

( 서버가 GET, POST 등의 요청 메서드를 인식하지 못할 때 사용 )

503 Service Unavailable : 서버의 유지보수로 작동이 중단되거나 과부하가 걸렸을 때 해당 코드를 보내게 됨.