[Next Step] 3장부터 4장까지 - HTTP Web Server 정리

Web Server

Web Server 를 시작하게 되면 클라이언트로부터 요청이 발생하는 것을 로그로 확인할 수 있다.

각 요청마다 클라이언트의 Port 는 서로 다른 Port 로 연결한다.

서버는 각 요청에 대해 순차적으로 실행하지 않고 Thread 를 생성하여 동시에 실행한다.

 

GET   /index.html      HTTP/1.1
GET   /css/styles.css   HTTP/1.1
GET   /js/scripts.js      HTTP/1.1
.
.
.

 

 

HTTP Status Code

html 의 form 태그는 GET 과 POST 메소드만 지원한다.

나머지 메소드(PUT, DELETE 등)는 AJAX 및 REST API 로 가능하다.

 

GET 은 서버에 존재하는 데이터(또는 자원)을 가져오는 것. 서버에 존재하는 데이터를 조회한다.

POST 는 서버에 요청을 보내 데이터 추가, 수정, 삭제와 같은 작업을 실행하도록 하는 것. 데이터의 상태를 변경한다.

 

POST 요청을 보낸 후, 새로고침을 한다면?

 

URL은  /user/create  상태이지만 화면은  /index.html  의 결과 화면을 출력한다.

새로고침을 하게 되면 요청을 또 보내게 되기 때문에 중복 요청이 발생한다.

그러므로 302 Status Code 로 요청을 분리해주어, Location 값을 읽어 서버에 재요청해준다.

1. Web Browser 에서  /user/create 로 요청
2. HTTP Web Server 에서 회원가입 처리
3. Web Browser 에게  /index.html 로 302 Status Code 응답
4. Web Browser 가 HTTP Web Server 에게  /index.html  요청
5. HTTP Web Server 가  /index.html 를 읽는다
6. HTTP Web Server 가 다시 Web Browser 에게  /index.html 로 200 Status Code 응답

302 Status Code 방식은 redirect 방식이라고도 한다.

 

2xx : 성공. 클라이언트가 요청한 동작을 수신하여 이해했고 승낙했으며 성공적으로 처리.
3xx : 리다이렉션. 클라이언트는 요청을 마치기 위해 추가 동작이 필요함.
4xx : 요청 오류. 클라이언트에 오류가 있음.
5xx : 서버 오류. 서버가 유효한 요청을 명백하게 수행하지 못했음.

 

 

Stateless Protocol

HTTP 는 요청을 보내고 응답을 받으면 클라이언트와 서버 간의 연결을 끊는다. 그러므로 클라이언트의 행위를 기억하기 위한 목적으로 쿠키(Cookie)를 이용하는데, 성공/실패 여부에 따라 응답 헤더에 Set-Cookie 로 결과 값을 저장해주고 logined 가 true 인지 판단한다.

 

로그인을 예로 들어보자.

1. Web Browser 에서  /user/login 으로 요청
2. HTTP Web Server 에서 로그인 성공 후, Set-Cookie 헤더에 값 추가
3. HTTP Web Server 에서 Web Browser 로 HTTP 응답에 Set-Cookie 를 담아서 전달
4. Web Browser 에서  /user/list 로 요청 후, Cookie 전달
5. HTTP Web Server 에서 Cookie 필드 값을 통해 로그인 유무 판단
6. Web Browser 로 응답

Cookie 는 HTTP 에서 각 요청 간의 상태를 공유할 수 있는 유일한 방법이다. 그러나 서버가 전달하는 Cookie 정보는 클라이언트에 저장해 관리하기 때문에 보안 이슈가 있다.

 

이 단점을 보완하기 위해 Cookie 를 기반으로 하는 Session 이 등장한다. 이것은 상태 데이터를 서버에 저장한다는 것이 Cookie 와의 차이점이다.