꼭 알아둬야 할 HTTP

웹 프로그래밍은 HTTP(Hypertext Transfer Protocol)을 기반으로 동작한다. 이번 포스트에서는 웹 프로그래밍을 위해 꼭 필요한 HTTP에 대해서 살펴보자.

 

URL

 

URL 구성

URL(Uniform Resource Locator는 인터넷에서 리소스의 위치를 나타내는 주소로 사용되며 다음의 구조를 갖는다.

URL의 구조

요소	설명
프로토콜(protocol)	서버와 클라이언트 사이의 통신 규약 ex: HTTP, HTTPS, FTP
호스트(HOST)	리소스가 위치하는 서버의 도메인 이름이나 IP 주소
포트(Port)	리소스를 제공하는 서비스의 포트 번호로 일반적으로 HTTP는 80, HTTPS는 443을 기본으로 사용
경로(Path)	서버 내에서 리소스의 위치를 지정하는 디렉토리 경로나 파일 경로
쿼리스트링(QueryString)	URL에 추가적인 매개변수를 전달할 때 사용되며 '?' 다음에 key=value 형태로 작성되며 여러 개일 경우 '&' 문자로 연결 처리

 

request와 response

 

request

request는 클라이언트가 서버로 보내는 정보를 의미하며 다음의 정보로 구성된다.

• 요청 라인(Request Line) 요청의 종류와 주소를 포함한다. 일반적으로 HTTP 메서드와 요청 URL이 포함된다.
• 요청 헤더(Request Headers): 요청에 대한 부가적인 정보를 제공한다. 예를 들면 클라이언트 브라우저의 정보, 인증 토큰, 쿠키 등이 헤더에 포함된다.
• 요청 본문(Request Body): POST 또는 PUT 메서드를 이용해 서버에 데이터를 전송할 때 사용되며 HTML 폼 데이터나 JSON 데이터가 포함된다.

출처: https://developer.mozilla.org/en-US/docs/Web/HTTP/Overview

 

response

response는 서버가 클라이언트에 보내는 정보이며 다음과 같이 구성된다.

• 상태 라인(Status Line): 응답의 상태 코드와 상태 메시지가 포함된다.
• 응답 헤더(Response Header): 서버의 종류, 응답 길이, 캐싱 여부 등 응답에 대한 부가적인 정보를 제공한다.
• 응답 본문(Response Body): HTML, JSON, 이미지 등 클라이언트로 저달되는 내용이 담긴다.

출처:  https://developer.mozilla.org/en-US/docs/Web/HTTP/Overview

 

요청 메서드

 

요청 메서드

클라이언트가 서버에 요청을 보낼 때 사용하는 메서드로 주요한 메서드는 GET/POST/PUT/DELETE 등이 있다.

출처: https://ko.wikipedia.org/wiki/HTTP

 

GET VS POST

여러 방법 중 <form>을 통해서 서버로 요청을 날릴 때는 GET 방식과 POST 방식만이 사용된다.

방식	GET	POST
파라미터 전달 방식	request body가 없으므로 URL을 통해 전달  - 데이터가 노출되며 짧은 데이터만 전달 가능	URL이 아닌 request body를 통해 전달  - 데이터가 노출되지 않고 전송 길이에 제한이 없다.
보안성	데이터가 노출되므로 보안에 취약	데이터가 노출되지는 않아 GET 보다는 안전  - 암호화와는 무관('옆사람한테 안보인다.' 정도)
멱등성	동일한 요청에 대해 언제나 같은 결과 - 멱등	동일한 요청에 다른 결과 - 멱등하지 앟음
활용 예	리소스 조회, 검색(R) 등 정보 요청에 주로 사용	데이터 생성, 수정, 삭제 등 C, U, D 작업  - 로그인의 경우 R이지만 보안을 위해 POST 처리

 

DELETE & PUT VS PATCH

DELETE, PUT, PATCH는 주로 REST API서비스 개발을 위해 사용된다. 물론 GET이나 POST도 REST API에 사용된다.
REST API는 Java나 C의 API처럼 어떤 기능을 웹에서 사용할 수 있게 하고 그 결과로 데이터를 반환하는 형태로 진행된다. REST API에 대해서는 다음을 참조하자.

01.Rest

REST API는 URL로 네트워크 상에 있는 리소스를 지정하고 HTTP 메서드로 그것을 제어하는 방식으로 사용된다. 이 제어는 일반적으로 C/R/U/D로 성격을 구분할 수 있는데 다음은 HTTP 메서드와 C/R/U/D의 매핑을 보여준다.

Http Method	동작	예
GET	전체 리소스에 대한 정보 획득	http://example.com/api/orders : 모든 주문 내역 조회
	특정 조건에 맞는 모든 정보 획득	http://example.com/api/orders?from=100  : 100번 주문부터 모든 주문 내역 조회
	특정 리소스에 대한 정보 획득	http://example.com/api/orders/123 : 123번 주문에 대한 상세 내역 조회
POST	새로운 리소스 저장	http://example.com/api/orders : 새로운 주문 생성. 파라미터는 request body로 전달
PUT/PATCH	기존 리소스 업데이트	http://example.com/api/orders/123 : 123번 주문에 대한 수정. 파라미터는 request body로 전달
DELETE	기존 리소스 삭제	http://example.com/api/orders/123 : 123번 주문 삭제

PUT과 PATCH는 둘 다 업데이트에 사용되는데 둘의 차이는 다음을 참조하자.

https://goodteacher.tistory.com/538

[Spring] Update 시 Put vs Patch

 

상태코드

 

상태 코드

HTTP에서 상태코드란 클라이언트(브라우저)에게 서버의 응답 상태를 전달하는데 사용된다. 이는 클라이언트가 요청을 보냈을 때 서버의 처리 결과를 파악하고 적절한 조치를 취할 수 있도록 도와준다. 이런 상태 코드는 크게 5가지로 분류될 수 있다.

• 1XX대(정보 제공): 임시 응답으로 현재까지의 클라이언트 요청이 잘 처리되고 있으니 계속 진행하라는 의미
• 2XX대(성공): 클라이언트의 요청이 서버에서 성공적으로 처리됨
• 3XX대(리다이렉션): 요청을 처리할 주소가 변경되었으니 다시 시도하도록 함
• 4XX대(클라이언트 에러): 없는 페이지를 요청했거나 파라미터가 누락되는 등 클라이언트의 요청에 문제가 있음
• 5XX대(서버 에러): 프로그램 자체의 오류나 DB, 서버 등의 문제로 요청 처리에 문제가 있음

이처럼 각 번호대로 다양한 상태 코드가 존재하는데 그 와중에서 자주 사용되는 녀석들만 살펴보자.

 

2XX: 성공 응답

코드	의미	설명
200	OK(성공)	서버가 요청 처리에 성공함
201	Created(생성됨)	요청의 결과로 새로운 리소스가 생성됨(주로 POST, 일부 PUT 요청 성공 시)
202	Accepted(허용됨)	요청을 접수했지만 처리가 완료되지는 않음
204	No Content(콘텐츠 없음)	처리에 성공했고 클라이언트에게 돌려줄 내용은 없음(주로 DELETE요청 성공 시)

 

4XX: 클라이언트 에러

코드	의미	설명
400	Bad Request(잘못된 요청)	요청의 구문이 잘못됨
401	Unauthorized(권한 없음)	단어 뜻 자체는 권한 없음이지만 인증을 통과하지 않음을 의미
403	Forbidden(접근 금지됨)	해당 리소스에 대한 접근 권한이 없음. 401과의 차이점은 서버가 클라이언트가 누구인지 알고 있는 상태
404	Not Found(찾을 수 없음)	지정한 리소스를 찾을 수 없음
405	Method Not Allowed(허용되지 않은 메서드)	요청한 URI가 지정한 메서드를 지원하지 않음(GET만 지원하는데 POST로 요청 등)

 

5XX: 서버 에러

코드	의미	설명
500	Internal Server Error	클라이언트의 요청은 유효하지만 서버가 처리에 실패함

 

Statelessness(무상태성)과 세션, 쿠키

 

무상태성

무상태성은 서버가 클라이언트의 상태를 유지하지 않는다는 의미이다. 이에 따라 클라이언트의 요청(request) 하나 하나는 서버에서 독립적으로 처리되며 이전의 요청과 전혀 연관성이 없다.

이렇게 처리하는 이유는 다음과 같이 생각해볼 수 있다.

• 각 요청이 상관 없게 함으로써 서버의 수평적인 확장이 가능하도록 하며 요청을 여러 서버로 분산해서 부하를 분담할 수 있게한다.
• 동일한 요청에 대해서 동일한 결과가 반환될 수 있어서 캐싱이 용이해진다.
• 상태 유지가 필요 없으므로 서버의 구현이 단순화 된다. 

상태를 관리하지 않는다는 말은 첫 번 요청에서 로그인에 성공했다고 하더라도 두 번째 요청에서 다시 로그인을 해야 한다는 이야기다. 즉 서버와 클라이언트간의 상호 작용에 있어서 매번 모든 정보를 요청과 응답에 포함시켜야 한다. 

따라서 필요한 경우에 클라이언트의 상태를 유지시키기 위해서 쿠키나 세션같은 메커니즘을 사용한다.

 

쿠키

쿠키는 웹 서버가 클라이언트 즉 브라우저에 저장하는 데이터 조각으로 여기에 클라이언트의 상태를 저장하고 서버에서 클라이언트를 식별하는데 사용된다. 

쿠키는 클라이언트가 웹사이트에 처음 접속할 때 서버에서 생성되서 브라우저에 전달/저장되고 이후에는 동일한 서버를 방문할 때마다 서버로 자동 전송된다. 

쿠키의 동작 방식

 

쿠키는 클라이언트에 저장되기 때문에 서버 입장에서는 별다른 부담이 없지만 네트워크를 타고 쿠키가 전달되기 때문에 암호화 등 보안에 신경써서 사용해야 한다. 또한 브라우저를 닫더라도 쿠키는 지정된 유효기간 동안 삭제되지 않는다.

 

세션

세션은 서버에 클라이언트의 상태값을 저장하는 기술로 하나의 클라이언트(브라우저)당 하나의 세션이 성립된다. 

세션이 동작하기 위해서는 서버의 저장소에 접근할 수 있는 키를 전달하기 위한 최소한의 쿠키인 session_id가 사용된다. 최초 클라이언트가 서버로 요청하면 서버는 클라이언트를 위한 저장 공간을 세션에 마련하고 이 공간에 접근할 수 있는 키를 쿠키를 통해 반환한다. 이후 클라이언트는 요청할 때마다 session_id를 서버로 전달하고 이 값을 이용해 세션 공간에 접근하게 된다.

세션의 동작 방식

 

세션은 쿠키와 달리 정보를 서버에 저장하기 때문에 상대적으로 보안에 대한 위험은 적지만 서버의 메모리를 사용하기 때문에 적절한 관리가 필요하다. 세션 쿠키는 브라우저를 닫으면 바로 삭제되기 때문에 브라우저를 닫으면 세션도 종료된다. 만약 서버에서 세션 공간을 삭제하지 않는다면 존재하지 않는 사용자를 위해 세션 공간을 낭비하는 상황이 올 수 있다.