그림으로 배우는 HTTP network basic 책 스터디 내용정리

1. WWW을 구성하는 3가지 핵심요소

   • HTML(HyperText Markup Language) - SGML을 베이스로한 문서 기술 언어
   • HTTP - 문서 전송 프로토콜
   • URL(Uniform Resource Locator) - 문서의 주소를 지정하는 방법

2. http://user:pass@www.example.jp:80/dir/index.htm?uid=1#ch1

   • http 스키마
   • user:pass 자격정보
   • www.example 서버주소
   • 80 서버포트
   • index.htm 계층적 파일 패스
   • uid=1 쿼리 문자열
   • ch1 프래그먼트 식별자
3. 아래 리퀘스트 메시지에서 구성요소 5가지를 구분하시오.

(메소드)POST (URI)/form/entry (프로토콜 버전)HTTP/1.1 (리퀘스트 헤더필더) [Host: hackr.jp Connection: keep-alive Content-Type: application/x-www-form-urlencoded Content-Length: 16]

(엔티티)name=ueno&age=37

4. 아래 리스폰 메시지에서 구성 요소를 5가지 구분하시오.

()프로토콜 버전)HTTP/1.1 (상태코드)200 (상태코드 설명)OK (리스폰스 헤더 필드)[Date: Tue, 10 Jul 2012 06:50:15 GMT Content-Length: 362 Content-Type: text/html]

(바디) …

5. HTTP 지속 연결 - HTTP 초기 버전에서는 HTTP 통신을 한 번 할 때마다 TCP에 의해 연결과 종료를 할 필요가 있었습니다. 왜냐하면 초기 통신을 작은 텍스트 사이즈만을 보내기 떄문 이였다. 하지만 이미지, 영상등이 등장하면서 쓸데없는 통신량이 늘어나기 때문에 지속연결이 등장했다. 어느 한쪽이 명시적으로 연결을 종료하지 않는 이상 TCP연결을 계속 유지합니다. TCP 커넥션의 연결과 종료를 반복되는 오버헤드를 줄여주기 때문에 리퀘스트와 리스폰스가 빠르게 완료된다. 그렇기 때문에 웹페이지를 빠르게 보여줄 수 있다.
6. 파이프라인은 여러 리퀘스트를 보낼 수 있도록 하는 것이다. 그니까 리퀘스트 후에 리스폰스를 수신할때 까지 기다리고 리퀘스트를 발행하던 것을 이제는 리스폰스를 기다리지 않고 바로 리퀘스트를 보낸다는 소리다.
7. stateless는 리퀘스트와 리스폰스의 상태를 관리하지 않는다. 과거 상태를 근거로 해서 현재 리퀘스트를 처리한다는 것은 불가능하다. 하지만 상태를 유지하지 않는다는 점에서 서버의 CPU나 메모리 같은 리소스의 소비를 억제할 수 있다.
8. 상태를 서버에서 관리하지 않는다는 이유때문에 쿠키가 등장했다. 쿠키는 리퀘스트와 리스폰스에 쿠키 정보를 추가해서 클라이언트의 상태를 파악하기 위한 시스템이다. 쿠키는 서버에서 리스폰스로 보내진 set-Cookie라는 헤더 필드에 의해 쿠키를 클라이언트에 보존하게 됩니다. 다음 번에 클라이언트가 같은 서버로 리퀘스트를 보낼 때. 자동으로 쿠키 값을 넣어서 송신합니다. 서버는 클라이언트가 보내온 쿠키를 확인해서 어느 클라이언트가 접속했는지 체크하고 서버 상의 기록을 확인해서 이전 상태를 알 수 있습니다.

9. HTTP메시지 구성 요소는

   • 메시지 헤더 - 서버와 클라이언트가 꼭 처리해야 하는 리퀘스트와 리스폰스 내용과 속성
   • 개행문자[CR + LF] - 메시지 헤더와 메시지 바디 구분한다.
   • 메시지 바디 - 꼭 전송되는 데이터 그자체
10. 메시지 바디와 엔티티 바디의 차이점은
11. 메시지는 HTTP 통신의 기본 단위로 옥텟 시퀸스로 구성되고 통신을 통해서 전송됩니다.
12. 엔티티는 리퀘스트랑 리스폰스의 페이로드로 전송되는 정보로 엔티티 헤더 필드와 엔티티 바디로 구성됩니다.
13. Content Codings, Chunked transfer Coding의 차이점
14. Content Codings - 콘텐츠 코딩은 엔티티에 적용하는 인코딩을 가리키는데 엔티티 정보를 유지한채로 압축합니다. 콘텐츠 코딩된 엔티티는 수신한 클라이언트 측에서 디코딩된다.
15. Chunked transfer Coding - 청크 코딩은 엔티티 바디를 청크 덩어리로 분해해서 보내고 수신한 클라이언트 측에서 원래 엔티티 바디로 디코딩한다.
16. HTTP에서 Multipart는 메일로 텍스트나 영상 이미지와 같은 여러 다른 데이터를 다루기 위한 기능을 사용하고 있다. 멀티파트는 각각의 엔티티를 구분하기 위해 ‘boundary’ 문자열을 사용합니다.
17. 콘텐츠 네고시에이션이란 웹페이지에는 영어와 한국어와 같이 서로 다른 언어를 주로 사용하는 브라우저가 같은 URI에 엑세스할 때에 각각 영어판 웹 페이지와 한국어판 웹 페이지를 표시한다. 이와 같은 구조를 콘텐츠 네고시에이션이라고 한다. 즉 클라이언트에 더욱 적합한 리소스를 제공하기 위한 구조다.
18. 상태 코드의 역할은 클라이언트가 서버를 향해 리퀘스트를 보낼때 서버에서 그 결과가 어떻게 되었는지 알려주는 것이 상태 코드의 역할이다.
19. 상대코드
20. 1xx - 리퀘스트를 받아들여 처리중
21. 2xx - 리퀘스트를 정상으로 처리했음
22. 3xx - 리퀘스트를 완료하기 위해서 추가 동작이 필요하다.
23. 4xx - 서버는 리퀘스트 이해가 불가능하다.
24. 5xx - 서버는 리퀘스트 처리를 실패했다.

25. 프록시

    1. 캐싱 프록시 - 프록시 서버 상에 리소스 캐시를 보존해 주는 타입의 프록시
    2. 투명 프록시 - 프록시로 리퀘스트와 리스폰스를 중계를 할 때 메시지 변경을 하지 않는 타입의 프록시
26. 게이트웨이는 클라이언트와 게이트웨이 사이를 암호화하는 등으로 안전하게 접속함으로써 안전성을 높이는 역할을 한다. 게이트 웨이를 사용함으로써 HTTP 리퀘스트에 의해 다른 프로토콜을 실행할 수 있다.
27. 터널은 요구에 따라서 다른 서버와의 통신 경로를 확립합니다. 이 때 클라이언트는 SSL 같은 암호화 통신을 통해 서버와 안전하게 통신하기 위해 사용합니다.
28. 캐시서버의 장점은 캐시를 이용함으로써 같은 데이터를 몇 번이고 오리진 서버에 전송할 필요가 없다는 것입니다. 캐시는 유효기간이 있다. 캐시가 오래되면 새로운 캐시를 사용해야하는데 그러기 위해서 유효기간이 다 되면 오리진서버에 다녀와서 다시 갱신한다.
29. 4종류의 HTTP 헤더 필드

30. 일반적 헤더 필드

    • 리퀘스트 메시지와 리스폰스 메시지 둘 다 사용되는 헤더입니다.

31. 리퀘스트 헤더 필드

    • 클라이언트 측에서 서버 측으로 송신된 리퀘스트 메시지에 사용되는 헤더로 리퀘스트의 부가적 정보와 클라이언트의 정보, 리스폰스의 콘텐츠에 관한 우선 순위 등을 부가한다.

32. 리스폰스 헤더 필드

    • 서버 측에서 클라이언트 측으로 송신한 리스폰스 메시지에 사용되는 헤더로 리스폰스의 정보와 서버의 정보, 클라이언트의 추가 정보 요구 등을 부가합니다.

33. 엔티티 헤더 필드

    • 리퀘스트 메시지와 리스폰스 메시지에 포함된 엔티티에 사용되는 헤더로 콘텐츠 갱신 시간 등의 엔티티에 관한 정보를 부가합니다.
34. End-to-end헤더는 리퀘스트나 리스폰스의 최종 수신자에게 전송됩니다. 캐시에서 구축된 리스폰스 중 보존되야 하고, 다시 전송되지 않으면 안되도록 되어 있습니다. Hop-by-hop헤더는 한 번 전송에 대해서만 유효하고 캐시의 프록시에 의해서 전송되지 않는 것도 있다. HTTP/1.1과 그 이후에서 사용되는 것은 Connection헤더 필드에 열거해야 합니다.
35. 클라이언트의 리퀘스트로 no-cache 디렉티브가 사용된 경우, 캐시된 리스폰스를 클라이언트가 받아 들이지 않음을 나타냅니다. 즉 중간 캐시 서버가 오리진 서버까지 리퀘스트를 전송해야한다. 서버의 리스폰에 no-cache 디렉트가 사용된 경우, 캐시 서버는 리소스를 저장할 수가 없습니다.

36. Connection 헤더 필드의 역할은

    • 프록시에 더 이상 전송하기 않는 헤더 필드를 지정
    • 지속적 접속 관리
37. Upgrade 헤더 필드는 HTTP 및 다른 프로토콜의 새로운 버전이 통신에 이용되는 경우에 사용됩니다. Upgrade 헤더 필드를 사용하는 경우는 Connection:Upgrade도 지정할 필요가 있습니다.
38. Via 헤더필드는 클라이언트와 서버 간의 리퀘스트 혹은 리스폰스 메시지의 경로를 알기 위해서 사용됩니다. 프록시 혹은 게이트웨이는 자신의 서버 정보를 Via 헤더 필드에 추가한 뒤에 메시지를 전송합니다. 프록시하는 경우에 반드시 부가할 필요가 있다.
39. Accept-Language 헤더 필드는 유저 에이전트가 처리할 수 있는 자연어의 세트와 자연어 세트의 상대적인 우선 순위를 천달하기 위해 사용된다. 여러개를 한번에 지정할 수 있는데 Accept-Language: ko-kr, en-us;q=0.7, en; q=0.3는 1순위는 한국어 2순위는 영어라는 소리다.
40. HTTP/1.1에서 유일한 필수 헤더필드는 Host 헤더 필드다. 리퀘스트가 서버에 오면 호스트명을 IP 주소로 해결해 리퀘스트가 처리됩니다. 이 때 같은 IP주소로 복수의 도메인이 적용되어 있다고 한다면 어느 도메인에 대한 리퀘스트인지 알 수가 없습니다. 그래서 Host 헤더 필드에 리퀘스트를 받을 호스트명을 명확하게 해둘 필요가 있습니다.
41. ETag 헤더필드는 엔티티 헤더필드라고 불리며, 일의적으로 리소스를 특정하기 위한 문자열을 전달합니다.
42. Location 헤더 필드는 리스폰스의 수신자에 대해서 Request-URI 이외의 리소스 엑세스를 유도하는 경우에 사용됩니다.
43. Vary 헤더 필드는 캐시를 컨트롤하기 위해서 사용합니다. 오리진 서버가 프록시 서버에 로컬 캐시를 사용하는 방법에 대한 지시를 전달합니다.
44. Content-MD5는 메시지 바디가 변경되지 않고 도착했는지 확인 하기 위해 MD5 알고리즘에 의해서 생성된 값을 전달한다. 클라이언트가 수신한 단계에서는 메시지 바디도 Content-MD5 헤더 필드도 변조되어 있기 때문에 발견할 방법이 없다.
45. 쿠키의 Expires 속성을 생략한경우, 쿠키는 부라우저 세션이 유지되고 있는 동안만 유효하게 됩니다. 이것의 통상은 브라우저 애플리케이션을 닫을 때까지 입니다. 유효기간이 지났다면 쿠키를 덮어 쓰는 것으로 실질적인 클라이언트 측의 쿠키를 삭제하는 것이 가능합니다.
46. 쿠키의 도메인 속성을 지정하면 쿠키를 생성한 도메인 전체에 쿠키가 송출된다. 명시적으로 여러 도메인에 대해서 쿠키를 송출하는 경우는 제외하고 쿠키는 도메인 속성을 지정하지 않는편이 안전하다.
47. 쿠키에서 secure 속성은 웹 페이지가 HTTPS에서 열렸을 때에만 쿠키 송출을 제한하기 위해서 지정합니다.
48. HttpOnly 속성이 부여된 Cookie는 javascript의 document.cookie에서는 읽어들일 수 없게 됩니다. 그렇기 때문에 XSS에서 Javascript를 이용해 쿠키를 훔칠 수 없습니다.
49. 통신 암호화 - SSL이나 TLS라는 다른 프로토콜을 조합함으로써 HTTP의 통신 내용을 암호화 할 수 있다. 콘텐츠 암호화 - 콘텐츠의 내용 자체를 암호화 해버리는 방법이다. 즉 메시지를 암호화해서 보낸다.
50. 위장 가능성을 방지하기 위해선 증명서를 이용한다. 증명서는 신뢰할 수 있는 제 3자 기관에서 발행된다.
51. 변조가능성을 방지하기 위해선 MD5, PGP, SHA-1, 디지털 서명 등을 사용한다. 하지만 모두 변조가 가능하기 때문에 한계가 있다.

52. HTTPS의 프로토콜 계층 구조는 다음과 같다.

    • 애플리케이션
    • SSL
    • TCP
    • IP
53. 공통키 암호는 암호화와 복호화에 하나의 키를 같이 사용하는 방식을 말한다. 공통키 암호화 방식은 상대방에게 키를 넘겨주는 것인데, 이때 네트워크로 넘길때 탈취가 가능하다. 그리고 키를 안전하게 보관하여야만 한다. 그래서 공개키 방식응 사용한다. 공개키는 클라이언트가 서버에게 데이터를 보낸다고 가정할 때 서버의 공개키를 받아오고 이를 사용하여 데이터를 암호화 한 뒤 서버에게 전송한다. 그러면 서버는 자신이 갖고 있는 비밀키로 복호화하여 데이터를 확인한다. 공개키를 가져가도 공개키로는 암호화된 메시지를 볼 수 없기때문에 공통키 딜레마를 해결 가능하다.
54. HTTPS 하이브리드 암호 시스템이란 공개키는 단점이 매우 느리다. 그래서 HTTPS에서는 키를 교환하는 곳에서는 공개키 암호를 사용하고 그 후의 통신에서 메시지를 교환하는 곳에서는 공통키 암호를 사용한다.
55. 공개키 증명서가 필요한 이유는 공개키가 진짜 인지 증명하기 위해서 사용한다.

56. 인증기관의 비밀키와 공개키를 이용해서 서버 클라이언트가 메시지를 송수신하는 과정

    1. 서버의 공개키를 인증기관에 등록
    2. 인증 기관의 비밀키로 서버의 공개키에 디지털 서명으로 공개키 증명서를 작성 등록
    3. 서버의 공개키 증명서를 입수하고 디지털서명을 인증기관의 공개키로 검증하고, 공개키가 진짜인지 확인
    4. 서버의 공개키로 암호화해서 메시지를 송신 기관에 등록
    5. 서버의 비밀키로 복호화
57. 클라이언트 증명서는 서버와 통신하고 있는 클라이언트가 서버가 의도가 상대라는 것을 증명해준다. 하지만 문제는 증명서 입수와 배포에 있다. 증명서는 유료이기 때문에 비용이 들고, 클라이언트의 실재를 증명할 뿐, 사용자의 존재 유무를 증명하지 않는다.

58. HTTPS 통신과정

    1. 클라이언트가 Client Hello 메시지를 송신하면서 SSL 통신을 시작한다.
    2. 서버가 SSL 통신이 가능한 경우에는 Sever Hello 메시지로 응답한다.
    3. 서버가 Certificate 메시지를 송신합니다.
    4. 서버가 Hello Done 메시지를 송신하여 SSL 네고시에이션 부분이 끝났음을 알려준다
    5. SSL의 최초 네고시에이션이 종료되면 클라이언트가 Client Key Exchange로 응답한다.
    6. 클라이언트는 Change Cipher Spec 메시지를 송신한다.
    7. 클라이언트는 Finished 메시지를 송신한다.
    8. 서버에서도 마찬가지로 Change Cipher Spec 메시지를 송신한다.
    9. 서버에서도 마찬가지로 Finished 메시지를 송신한다.
    10. 서버와 클라이언트의 Finished 메시지 교환이 완료되면 SSL에 의해서 접속이 확립된다.
    11. 어플리케이션 계층의 프로토콜에 의한 통신 즉 HTTP 리스폰스를 송신한다.
    12. 마지막에는 클라이언트가 접속을 끊는다. 끊은경우 close_notify 메시지를 송신한다.
59. SSL 통신이 지연되는 이유는 TCP 접속과 HTTP 리퀘스트/리스폰스 이외에 SSL이 추가적으로 들어가기 때문에 처리해야 하는 통신이 증가하기 때문이다. 다른 한가지는 암호화나 복호화를 하기위한 CPU나 메모리등 리소스를 다량으로 소비해서 속도가 느려진다.

60. BASIC 인증 수순

    1. 클라이언트가 서버로 리퀘스트 송신
    2. 서버는 상태 코드 401로 응답해서 인증이 필요하다는 것을 전달
    3. 유저 ID와 패스워드를 Base64 형식으로 인코드한 것을 송신
    4. 서버는 인증성공시 200 상태 코드로 응답하고 실패시 401을 응답한다.

61. 폼 베이스 인증

    1. 클라이언트가 서버에 자격정보를 전달한다.
    2. 서버는 유저에게 세션ID를 발행한 수 인증상태를 기록한다.
    3. 서버는 세션 ID를 클라이언트에게 쿠키로 송신한다.
    4. 클라이언트는 받은 쿠키를 브라우저에 저장하고 로그인 요청이 필요할때 마다 쿠키로 세션ID를 송신한다.
    5. 서버는 세션ID를 확인후 사용자를 확인

62. HTTP에서 병목 현상의 원인이 되는 사양은?

    • 1개의 커넥션으로 1개의 리퀘스트만 보낼 수 있다.
    • 리퀘스트는 클라이언트에서만 시작할 수 있다. 리스폰스만 받는 것은 불가능하다.
    • 리퀘스트/리스폰스 헤더를 압축하지 않은 채로 보낸다. 헤더가 커질수록 지연이 심해진다.
    • 장황한 헤더를 보낸다. 매번 같은 헤더를 보낸다.
    • 데이터 압축을 임의로 선택할 수 있다. 강제적이지 않다.

63. WebSocket은 병목현상을 해결하기 위한 기술이다. 웹서버와 클라이언트가 한번 접속을 확립하면 그 뒤의 통신을 모두 전용 프로토콜로 하는 방식이다.

    1. 클라이언트가 핸드쉐이크 리퀘스트를 송신한다.
    2. 서버가 핸드쉐이크 리스폰스를 송신한다.
    3. WebSocker이라는 별도의 프로토콜로 변경한다.
    4. 양방향 통신이 가능하기 때문에 리퀘스트를 기다리지 않고 서버측에서 데이터 송신이 가능하다.
64. HTTP가 이렇게까지 사용되고 있는 이유는 현재 아주 많은 사람들이 HTTP를 이미 사용하고 있기때문이다.
65. HTML이란 웹 상에서 하이퍼텍스트를 보내기 위해서 개발된 마크업 언어다. 하이퍼텍스트란 문서 시스템중 하나로 문서중에 임의의 장소의 정보가 다른 정보에 링크되어 있는 문서를 말한다.
66. CSS란 HTML 각 요소를 어떻게 표시할지를 지시하는 것으로, 스타일 시트라고 불리는 사양중의 하나다. CSS는 문서의 구조와 디자인을 분리한다는 이념에서 만들어졌다.
67. DOM은 HTML 문서와 XML 문서를 위한 API다. DOM을 사용하면 HTML내의 요소를 오브젝트로 다룰 수 있다. 그래서 Javascript를 사용하면 HTML을 조작할 수 이싿.
68. 웹 어플리케이션이란 웹 기능을 사용해서 제공되는 프로그램이다. 이러한 프로그램에 의해서 생성된 콘텐츠를 동적 콘텐츠, 기존에 준비되어있던 콘텐츠를 정적 콘텐츠라고 한다.
69. CGI는 웹 서버가 클라이언트에서 받은 리퀘스트를 프로그램에 전달하기 위한 구조이다. CGI에 의해 프로그램은 리퀘스트 내용에 맞게 HTML을 생성하는 등으로 동적 콘텐츠를 생성할 수 있다. 이것은 리퀘스트마다 프로그램을 기동하기 때문에 대량으로 엑세스가 있을경우 서버에 부하가 걸리기 때문에 서블릿을 사용한다. 서블릿은 서버상에 HTML 등의 동적 콘텐츠를 생성하기 위한 프로그램으로 웹서버와 같은 프로세스 속에서 동작하기 때문에 비교적 부하를 적게 동작시킬 수 있다.
70. XML이란 목적에 맞게 확장 가능한 범용적으로 사용할 수 있는 마크업 언어다. HTML, XML 둘다 기술언어이긴 하나 XML이 데이터를 기술하는 것에 특화되어 있다. 기본적으로 XML 구조는 태그로 나뉘어져 있고 트리 구조로 되어 있기 때문에 데이터 관리를 편하게 할 수 있다.
71. JSON은 경량 데이터 기술언어로서 JavaScript에 있어서 오브젝트 표기법을 바탕으로 하고있다. JSON 데이터는 단순하고 가볍게, 게다가 문자열을 JavaScript에서 간단하게 읽어올 수 있는 점에서 많이 사용한다.