HTTP 웹 구현 후 알게된 점

HTTP 웹 서버 만들기

직접 HTTP Request, Response를 작성하다보니 HTTP Header 형식이 많이 친숙해졌다.

어느정도 리팩토링이 진행된 단계에서 자바지기 박재성 님과 알게된 점, 궁금한 점에 대해 이야기를 갖는 시간을 가졌다. 기억에 남는 부분을 포스팅해본다. (제대로 기억하고 있는거겠지 ㅡㅡ?)

추가적으로, 이번에 너무 좋은 사이트를 발견했다.

---

1. status code 301과 302의 차이는 무엇인가? - 301은 Client단에 정보를 남겨 cookie가 남아있는한 설정된 URL로 연결된다. - 302는 서버에 웹 페이지 요청시 다른 URL로 연결시킨다.

---

2. HTTP stateless 특성을 보완하기 위한 방법

- 무상태 프로토콜의 단점을 보완하기 위해 polling 방식, long polling 방식, websocket(State Protocol) 등이 활용된다. - Stateless한 HTTP Protocol을 사용하면서 Server와 Client를 식별하기 위해 cookie와 Session을 사용하게 되었다.

- Http Session은 Servlet 스펙이다. - 세션도 Cookie를 사용한다. (Session ID 값을 Cookie로 보냄) - set-cookie로 서버는 브라우저에게 cookie 만료 일자 등을 지정할 수 있다.(생각보다 HTTP header로 다룰 수 있는 것이 참 많다)

- 관련해서 궁금한 점은? - 3 Tier 구조에서 WAS 가 한대가 아닐 경우 Session은 어떻게 유지 되나요? (LoadBalancing 될 경우 동일한 WAS 장비과 통신하지 않을 수도 있지 않나요?) - 1) LoadBalancer에 Sticky Session 기능을 지원할 경우 이를 활용 (L7 장비 혹은 HAProxy 등 Software적으로 해결) - 2) DB에 Session Data 저장 (이 경우 보통 redis, memcached 등의 nosql을 사용한다. 데이터 입력에 milli second밖에 안 들 정도로 빠르다.) 이를 Global Session이라 한다. - 3) Session Clustering (WAS간 Session Repository 동기화 -> 부하가 높아서 잘 안쓰임)

---

3. status code 의미는? - 대표적으로 이해할 필요가 있는 status code - 101 - switching protocol. Web Socket과 같이 protocol 변경시 사용 - 200 - OK - 201 - Created - 301 - Moved permanently - 302 - Found(HTTP 1.0) - 303 - See Other((HTTP 1.1) - 307 - Temporary Redirect(HTTP 1.1) - 304 - Not Modified - 401 - Unauthorized - 404 - Not Found - 500 - Internal Server Error - 503 - Service Unavailable - 2XX : 성공. 클라이언트가 요청한 동작을 수신하여 이해했고 승낙했으며 성공적으로 처리 - 3XX : 라다이렉션 완료. 클라이언트는 요청을 마치기 위해 추가 동작이 필요함. - 4XX : 요청 오류. 클라이언트에 오류가 있음 - 5XX : 서버 오류. 서버가 유효한 요청을 명백하게 수행하지 못했음

---

4. 성능 좋은 웹 애플리케이션 개발을 위한 HTTP 학습

- 가고 싶은 회사의 웹 페이지 성능을 확인해보자 ! (https://developers.google.com/speed/pagespeed/insights/)

흙 네이버 점수가 왜이럼 ㄷㄷ; 구글은 100점인데...

1) 무엇을 캐싱해야 할까? HTTP 캐싱(https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/http-caching) - HTML, Image, CSS, JS 모두 개별적으로 요청하고 받을 경우 네트워크 비용이 높다. 그러므로 정적자원(Image, CSS, JS)들은 캐싱하여 사용하자. HTTP Header의 cache-control로 캐싱 만료 기간 등을 지정할 수 있으며, path별로 header를 다르게 구성하는 등의 전략이 가능하다. 2) 압축?? (https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/optimize-encoding-and-transfer)

- 서버에서 압축하고 header에 content-encoding으로 압축방식을 알려주면 브라우저가 알맞게 decoding한다. - 구글은 이미지들을 data encoding 해서 바이너리 형태로 보낸다.

(브라우저별로 비교테스트 http://www.browserscope.org/?category=network&v=top)

---

- 현재 내가 만든 Http Web은 매 요청마다 Thread를 생성한다. 효율성을 제고하기 위해서는 Thread pool을 구성하면 된다. (기본값은 200) Thread pool의 자원이 다 사용되면 Queue를 통해 대기하게 된다. (DB Connection pool은 소켓 재사용) ​ ​