HTTP란?

HyperText Transfer Protocol의 줄임말로, HTML문서와 같은 리소스들을 가져올 수 있도록 해주고, 웹에서 다양한 데이터를 주고 받을 때 사용되는 프로토콜이다 TCP/IP모델에서 Application Layer에 위치한 프로토콜이다.

HTTP의 특징

1. 간단하고 사람이 읽기 편하다
   • 말그대로 HTTP는 사람이 읽을 수 있도록 간단하게 만들어졌다.
   • HTTP메세지를 프레임 별로 캡슐화하여 간결함을 유지하였다.

2. 무상태 프로토콜(stateless)
   - HTTP에서 서버는 클라이언트 상태를 저장하지 않는다. (상태를 저장하지 않는다는 말은 클라이언트의 정보를 가지지 않는다와 동일하다고 볼 수 있다!))
   
   • 서버의 확장성을 좋으나, 클라이언트가 추가 데이터를 전송해야한다는 단점이 있다. (때문에 로그인과 같이 유저의 상태를 계속 유지해야하는 서비스라면 쿠키,세션,토큰등을 이용해서 상태를 유지한다.)
3. 비연결성
   • 클라이언트와 서버가 계속해서 연결을 유지한다면 서버의 자원이 계속해서 소모된다. 하지만 HTTP는 요청을 주고 받을 떄만 연결을 유지하고 끝나게 되면 TCP/IP연결을 끊는다.
   • 1.0에선 각각의 데이터를 다운받기 위해서 연결과 종료가 반복되는 방식이었다.(3way handshake 시간만큼 계속해서 추가 되었다.) 1.1부터는 지속연결이 가능하게 되었다. 각각의 자원들을 요청하고 응답을 받은 뒤, 연결을 종료할 수 있게 되었다.
   • 이론상으론 3way Handshake방식으로 연결, 요청응답, 종료가 이루어지는데 현실적으론 끊지않고, 계속 연결하고 요청 응답이 이루어진 다음, 종료하지않고 계속 된다.

HTTP Request Message

HTTP Request Message는 클라이언트가 서버에서 데이터를 받기위해 요청 보내는 메세지이다.
Request Message는 크게 요청라인(Request Line), 요청헤더(Request Header), 공백라인(A Blank Line), 요청바디(Request Message Body)로 나뉜다.

ex)

GET /1.html HTTP/1.1 } //Request Line
Host : localhost : 8080 // 밑에부터 Request Header
Connection : keep-alive
Cache-Control : max-age = 0
Upgrade-Insecure-Requests : 1
User-Agent : Mozilla/5.0 (클라이언트 컴퓨터의 정보)
Accept : image/gif, image/jpeg

1. Request Line : 클라이언트가 서버에게 보내는 요청메소드, 프로토콜 버전등의 정보가 담겨있다.
   • 요청 메서드 : 예시에선 Get메서드를 가지고 있다.
   • 요청하는 데이터 : 1.html이라는 정보를 서버에게 요청하고 있다.
   • 클라이언트가 사용하고 있는 HTTP 정보 : HTTP 1.1을 사용하고 있다고 서버에게 알리고 있다.
2. Request Header
   • Host : 클라이언트가 요청한 도메인의 정보가 들어있다.
   • User-Agent : 사용자 웹 브라우저 종류 및 버전 정보, 운영체제 버전 등이 적혀있다.
   • Accept : 웹 서버로부터 수신되는 데이터 중 웹브라우저가 처리할 수 있는 데이터 형식.

그 외의 정보.
1. Referer : 이전 경유한 웹페이지 주소
2. Cookie : 쿠키의 정보
3. Content : 콘텐츠란 요청 본문(Request Body)에 관련된 내용을 나타낸다.
- Content-Length : 메세지의 본문 크기를 byte단위로 표시
- Content-Type : 컨텐츠의 타입과 문자열 인코딩의 정보.
- Content-Encoding : 컨텐츠의 압축방식 정보.
- Content-Language : 사용된 언어


Request Message는 빈 줄(A blank line)을 기준으로 아래에는 Body(클라이언트가 서버에게 보내는 실제 데이터)의 내용이 적혀있다.

HTTP Status Code 정리

Response Message 에서 status code는 번호마다 다양한 정보를 담고 있다. 대표적으로 몇가지만 알아보자.

• 1xx(정보) : 요청을 받았으며 프로세스를 계속 진행합니다
  - 100 continue : 현재까지 진행상태는 문제없고, 진행중임을 의미한다.
  - 이론적으론 100을 보내고 다음 데이터를 받지만, 현실적으론 100을 받든말든 다음을 진행하는게 일반적이다.
  
  
• 2xx(성공) : 요청을 성공적으로 받았고, 수용했다는 뜻
  - 200 Ok : 요청이 성공적으로 되었다는 뜻
  • 201 Create : 요청이 성공적이었고, 그 결과 새로운 리소스가 생성 되었다는 뜻
  • 204 No Content : 요청에 대해서 보내줄 컨텐츠는 없지만 헤더는 유의미 할 수 있다.
    
    
• 3xx(리다이렉션) : 요청완료를 하기 위해서 추가적인 작업이나 정보가 필요하다는 뜻
  - 300 Multiple Choice : 요청에 대해서 하나 이상의 응답이 가능하다.
  
  
• 4xx(클라이언트 오류) : 클라이언트 측에서 요청의 문법이 잘못되었거나, 요청을 처리 할 수 없다는 뜻
  - 400 Bad Request : 이 응답은 잘못된 문법으로 서버가 이해할 수 없음을 의미.
  • 403 Forbidden : 클라이언트는 콘텐츠에 접근할 권리를 가지고 있지 않다는 뜻.
  • 404 Not Found : 서버는 요청받은 리소스를 찾을 수 없다는 뜻.
    
    
• 5xx(서버 오류) : 서버가 유효한 요청에 대한 응답을 실패했다는 뜻
  - 500 Internal Server Error : 웹서버에 문제가 있어서 진행할 수 없다는 뜻
  
  
  

HTTP Request Method

GET 메서드

• 리소스 조회 메서드이다.
• 클라이언트가 서버에게 데이터를 요청할떄 사용된다.
• 만약 서버에 전달하고 싶은 데이터의 위치를 알려주고 싶을 때 쿼리스트링 방식을 이용한다.
  쿼리스트링 : 쿼리스트링이란, 웹 요청에서 데이터를 전달하기 위한 일반적인 방법 중 하나이다. URL의 끝에 '?'로 시작하여 key-value로 데이터를 제공한다. 이 쿼리를 서버로 전달하고, 전달받은 서버는 분석하여 클라이언트에게 원하는 데이터를 제공한다.
  ex)

•  https://example.com/search?query=apple&category=fruits

• 요청정보는 사용자가 확인할 수 있지만, POST보다 보안이 취약하다는 단점이 있다.
• 조회할 때 POST를 사용할 순 있지만, GET메서드는 캐싱이 가능하기 때문에 GET을 사용하는 것이 유리하다.

POST 메서드

• 클라이언트가 서버에게 전달할 데이터를 처리/생성을 요청하는 메서드이다.
• 메세지 바디를 통해 서버로 요청 데이터를 전달하면 서버는 데이터를 분석하여 업데이트한다.
• Body에 데이터가 숨겨져있어, 보안이 GET보다 강하고 대용량 데이터를 전송하기에 적합하다.
• GET과는 달리 캐싱을 사용할 수 없다.

PUT 메서드

• 클라이언트가 서버에 있는 데이터를 생성 및 수정을 요청할 떄 사용된다.
• 데이터를 POST처럼 새로 생성할 수 있지만, 원래 있는 데이터를 업데이트 할 떄 사용된다.
• 데이터를 다시 업데이트 해야하니, 클라이언트가 리소스의 구체적인 경로를 지정해 보내주어야한다.

DELETE 메서드

• 클라이언트가 서버에 있는 특정 데이터를 삭제하고 싶을때 요청한다.
• URL을 통해 삭제하고 싶은 데이터를 서버에게 알린다.

GET과 DELETE는 바디가 없다. 바디를 받는 서버도 있지만 바디를 받지않고 그냥 헤더만 보고 해석하는 서버도 있기 때문에 없다고 생각하는게 좋다.

무상태(Stateless)단점 극복을 위한 쿠키, 세션, 캐시

쿠키

• 쿠키는 클라이언트 측에 저장되는 작은 데이터 조각이다. 웹 어플리케이션과 브라우저 간 상태정보를 유지하는데 사용된다.
• 쿠키는 서버->클라이언트로 보내고, 클라이언트는 이를 저장하고 이후 요청 시 다시 서버로 보낸다.
• 이같은 기능으로 사용자 식별, 로그인 유지, 사용자 환경설정 등을 구현할 수 있다.
• 해당 사용자의 컴퓨터를 사용한다면 누구든지 쿠키에 입력된 값을 확인할 수 있기 떄문에 보안성이 낮다는 단점이 있다.

쿠키의 제약조건

• 클라이언트는 300개 정도의 쿠키를 가질 수 있고, 도메인 당 50~100개의 쿠키를 가질 수 있디. 만약 용량을 초과하면 적게 사용되는 것부터 삭제된다.
• 쿠키가 사용되는 갯수가 정해져있긴 하지만, 현실적으로 지켜지는 경우가 거의없다. 300개 넘도록 쓰는 경우가 훨씬 많다.
• 하나의 쿠키는 4kb미만으로 저장이 가능하다.

세션

• 서버에 저장되는 쿠키라고 보면된다. 클라이언트와 서버의 통신상태등 중요한 데이터를 저장시 사용된다.
• 세션은 일반적으로 고유한 세션 식별자를 사용하여 클라이언트, 서버간의 상태를 연결한다. 이를 통해 로그인 정보, 장바구니 내용을 유지한다.
• 사용자 로컬이 아닌 서버에 직접 저장되므로, 세션 내의 데이터를 탈취하는 것이 어려워 보안성이 비교적 높다.
• 서버 측 세션 관리와 클라이언트 측 쿠키를 사용하여 세션을 구현한다.
  
• 예시의 표를 가져왔지만 위 표에서 잘못된 부분이 잇다. 세션 라이프 사이클이 브라우저 종료시 삭제라고 나와있다. HTTP는 무상태 프로토콜 특징을 가지는데, 클라이언트가 종료되었는지 알 수 있는 방법이 없다. 그래서 세션은 서버가 죽지않는 이상 계속 살이있다.(물론 일정시간 요청이 없다면 삭제하는 방식되 있다.)

캐시

• 캐시는 리소스 파일들의 임시 저장소이다. 같은 웹페이지에 접속할 때 사용자의 PC에서 로드함으로 서버를 거치지 않는다.
• 이로써 웹페이지 로딩속도를 향상하고, 서버 부하를 줄인다.
• 웹 브라우저와 서버간의 캐시 제어 헤더를 통해 캐시 동작을 제어한다.

출처 및 참고

https://velog.io/@wlwl99/HTTP%EC%9D%98-%ED%8A%B9%EC%A7%95
https://cotak.tistory.com/59
https://inpa.tistory.com/entry/WEB-%F0%9F%8C%90-HTTP-%EB%A9%94%EC%84%9C%EB%93%9C-%EC%A2%85%EB%A5%98-%ED%86%B5%EC%8B%A0-%EA%B3%BC%EC%A0%95-%F0%9F%92%AF-%EC%B4%9D%EC%A0%95%EB%A6%AC#