1. 웹 브라우저가 메세지를 만든다

1. HTTP 리퀘스트 메세지를 작성한다

1.1 Http?

• 클라이언트와 서버가 주고받은 request/response 메세지의 내용이나 순서를 정한것이다.
• 웹은 HTTP라는 약속을 사용한 통신으로 이루어진다.
• request 메세지에는 무엇을(URI : 인터넷에 있는 자원을 나타내는 유일한 주소) , 어떻게해서 라는 (HTTP 메소드) 내용이 쓰여있다.
• request 메세지가 웹 서버에 도착하면 웹 서버는 메세지를 해독한다. 그리고 URL과 메세지를 조사하여 '무엇을', '어떻게 하는지' 판단한 후 요구에 따라 동작하고, 결과 데이터를 응답 메세지에 저장한다.

1.2 URI (Uniform Resource Identifier) 통합 자원 식별자

인터넷에 있는 자원을 나타내는 유일한 주소로 요청한 데이터가 저장되어 있는 장소를 URI라고 한다. 보통 페이지 데이터를 저장한 파일의 이름을 URI로 쓰고, 그대로 URL 로 쓸 수도 있다.

• 인터넷의 자원들을 식별할 수 있는 이름표 같은 역할.
• URI의 하위개념으로 URL이 있다.

1.3 HTTP 메소드

• GET : URI로 지정한 정보를 추출하여 내용을 돌려보낸다
• POST : 클라이언트에서 서버로 데이터를 송신한다
• PUT : URI로 지정한 서버의 파일을 치환한다.
• DELETE : 목적 리소스를 삭제한다.

1.4 HTTP Request/Response 메세지

Request 메세지

1. start-line : 실행되어야 할 요청, 또는 요청 수행에 대한 성공/실패가 한줄로 적혀있다. 이 한행으로 리퀘스트의 내용을 대략 알 수 있다.
2. HTTP headers : 한 행에 한 개의 헤더 필드를 쓴다. 이를 통해 request의 부가 정보를 나타낸다.
3. empty line : 요청에 대한 모든 메타 정보가 전송되었음을 알리는 빈줄이 삽입된다. 공백행까지가 메세지의 헤더가 된다.
4. body : 메세지 본문의 내용은 클라이언트에서 서버에 송신하는 데이터가 들어간다.

Response 메세지

Request 메세지와 비슷하다. 첫번째 행의 경우, request의 실행 결과를 나타내는 Status code와 응답 문구를 포함한다.

• 상태 코드
  • 1XX : 처리의 경과 상황 등을 통지
  • 2XX : 정상 종료
  • 3XX : 무언가 다른 조치가 필요함을 나타냄.
  • 4XX : 클라이언트측의 오류
  • 5XX : 서버측의 오류
• 웹 서버는 한 개의 request 에 대한 한 개의 response만 보냅니다 → 한 문장에 3개의 영상이 포함되어 있다면 문장 파일을 읽는 request와 영상 파일을 읽는 request로 총 4개의 request를 웹 서버에 보내야 합니다.

1.5 Connectionless, Stateless → 세션, 쿠키, 토큰

1. Connectionless (비연결성) 클라이언트가 서버와 한번 연결을 맺은 후, request에 대해 서버가 응답을 마치면 연결을 끊어버린다. HTTP 는 인터넷 환경상 불특정 다수의 통신 환경을 기반으로 설계되었기 때문에 서버에서 다수의 연결을 유지하는 리소스를 줄이고자 비연결적인 특징을 가진다.
2. Stateless (무상태) 비연결성으로 인해 서버는 클라이언트의 상태를 모른다. HTTP 는 요청에 따른 응답을 받으면 연결이 끊어지고 통신이 종료되면 어떠한 상태도 저장하지 않는다.

예를 들어, 로그인 후 웹 페이지에 다시 접속하면 다시 로그인을 해야하는 상황이 발생한다.

이러한 문제점을 해결하기 위해 서버가 클라이언트의 상태를 기억하는 방법으로 세션, 쿠키, 토큰기반의 인증 방식이 사용된다.

세션

• 서버가 사용자의 정보를 객체 형태로 저장한다
• 클라이언트를 구분하기 위해 세션 ID를 부여하며 웹 브라우저가 서버에 접속해서 브라우저를 종료할때까지 인증상태를 유지한다.
• 사용자가 많아질수록 서버 메모리를 많이 차지하는 단점이 있다.

쿠키

• 클라이언트 로컬에 저장되는 key-value 쌍의 데이터이다.
• 사용자가 설정하지 않아도 HTTP 가 request시 header에 자동으로 넣어진다.
• 쿠키는 단일 도메인 및 서브 도메인에서만 작동하기 때문에 여러 도메인에서 쿠키를 관리하는것이 어렵다.

토큰

• 쿠키와 세션의 문제점을 보완하기 위한 토큰 기반의 인증방식
• 보호할 데이터를 토큰으로 치환하여 원본 데이터 대신 토큰을 사용한다. 중간에 공격자로부터 토큰이 탈취당하더라도 데이터에 대한 정보를 알 수 없으므로 보안성이 놓다.
• 서버는 전달받은 토큰을 검증만 하면 되기 때문에 서버의 부담을 줄이고 서버의 확장성을 높일 수 있다. → 클라이언트는 서버에 요청을 할때마다 한번의 인증 과정을 거쳐 서버로부터 미리 Signed 받은 토큰을 HTTP 헤더에 같이 넣어서 보낸다.
• OAuth, JWT(JSON Web Token)

 

 

출처 : 성공과 실패를 결정하는 1%의 네트워크 원리