Hypertext Transfer Protocol
HTTP는 서버와 클라이언트가 인터넷상에서 데이터를 주고 받기 위한 프로토콜(protocol)
Protocol
서로 다른 하드웨어 기기 간 데이터 통신 규약
프로토콜 규칙의 역할들에 따라 TCP/IP 4계층으로 분리해 생각해야 한다.
클라이언트가 리소스를 HTTP를 통해 요청 >> TCP/IP 프로토콜을 걸쳐 서버 쪽의 HTTP까지 요청이 도달하게 되는데
이에 대한 응답을 다시 서버에서 HTTP로 보내면 TCP/IP 프로토콜을 통과해 클라이언트까지 응답이 도달하게 되는 것이다.
TCP/IP
수 많은 네트워크 기기들이 인터넷으로 통신하는 데 있어 가장 기반이 되는 프로토콜
트랜스포트 계층에서는 서버와 클라이언트 사이 통신 연결을 담당하게 되는데, 특이사항으로는 TCP에서는 바이트 스트림(Byte Stream) 서비스를 제공한다는 것이다.
데이터를 잘게 분해한 후 전송하는 서비스.
이때, 정확히 전송되었는지 확인하는 기술이 바로 "3Way handshaking"기법이다.
3way handshaking
TCP/IP 프로토콜에서 사용하는 연결 설정 방법으로, 클라이언트와 서버 간에 3번의 대화를 통해 안전하게 데이터를 주고받을 수 있도록 연결을 설정하는 것.
요청이 잘 넘어가는 지 계속 물어보고 이를 확인한 이후 데이터를 전송하는 개념. 이 때문에 TCP 프로토콜은 ‘신뢰성'을 담당한다고 말할수있다.
TCP 에서 연결된 것을 확인 했으니 데이터를 보내게 되는데 IP에서 이를 담당한다. 즉 IP에서 분할된 데이터 패킷을 보내게 된다.
보내는 주소는 어떻게 알 수 있을까?
IP주소를 생각하기 쉽지만 IP주소를 사용하게 되면 많은 문제점을 야기하게 된다.
고유하지 않기 때문에 신뢰성이 떨어지기 때문이다.
따라서 MAC주소를 사용하게된다.
MAC
컴퓨터 네트워크에서 각각의 기기를 식별하기 위한 고유한 주소로, 하드웨어에 고정되어 있으며 IP 주소와는 다른 개념이다.
그렇다면 왜 패킷을 보내는 과정에서 IP를 사용하게 되는 것 일까?
바로 "방향성" 때문이다. 이 과정에서 ARP라는 개념이 나온다.
주소를 찾아가는 프로토콜이란 뜻으로 ARP는 수신자의 IP주소로 수소문하고 도착한 곳 기기의 MAC 주소를 조사하여 이를 통해 배송지의 루트를 찾아내게된다.
이때 중간에 경유하는 네트워크 기기들은 전체 배송지의 루트를 알 수 없다.
ARP에서도 중간의 경유되는 네트워크 기기들이 데이터를 배송할 다음 기기 위치만 알면된다는것이다.
위 Request는 메서드 (GET), URI (/doc/test.html ),프로토콜 버전 (HTTP/1.1),헤더,바디로 구성되어있다.
Response는 프로토콜 버전(HTTP/1.1), 상태코드 (200), 상태코드 설명(OK), 헤더, 바디로 구성되어 있다.
HTTP 프로토콜은 기본적으로 Stateless(무상태성)을 가지고 있다.
Http 포로토콜에서는 과거 정보를 남기지 않고, 상태가 필요한 경우에 처리해야할까?
상태를 유지하고자 할 경우 이를 보완하고자 세션과 쿠키 같은 기술을 함께 사용해 이를 해결하면된다.
메서드는 요청의 종류를 서버에게 알려주기 위해서 사용한다.
GET : 주어진 URL에서 자원을 요청
POST : 주어진 URL로 자원의 생성을 요청
PUT : 주어진 URL로 자원의 대체를 요청
DELETE : 주어진 URL로 자원의 삭제를 요청
HEAD : 주어진 URL에서 자원의 헤더만을 요청, 해당 자원이 존재하는지 혹은 서버에 문제가 없는지를 확인하기 위해서 사용한다.
OPTIONS : 주어진 URL에서 처리 가능한 메소드의 목록을 요청
각 용도에 맞는 메서드가 준비돼 있음에도 GET과 POST만으로도 모든 종류의 요청을 표현할 수 있다.
명시적으로 메서드를 사용하지 않아도 웹 서비스 개발에 큰 문제는 없지만, Restful API 서버의 경우에는 GET, POST, DELETE, PUT을 명시적으로 구분한다.
자원의 위치 뿐만 아니라 자원에 할 일 까지 명확히 명시할 수 있기 때문에, Open API 서버를 만들기 위해서 널리 사용한다.
상태 코드에는 굉장히 많은 종류가 있다. 모두 숫자 세 자리로 이루어져 있으며, 아래와 같이 크게 다섯 부류로 나눌 수 있다.
1XX (조건부 응답) : 요청을 받았으며 작업을 계속한다.
2XX (성공) : 클라이언트가 요청한 동작을 수신하여 이해했고 승낙했으며 성공적으로 처리했음을 가리킨다.
3XX (리다이렉션 완료) : 클라이언트는 요청을 마치기 위해 추가 동작을 취해야 한다.
4XX (요청 오류) : 클라이언트에 오류가 있음을 나타낸다.
5XX (서버 오류) : 서버가 유효한 요청을 명백하게 수행하지 못했음을 나타낸다.