"그림으로 배우는 Http & Network Basic"

https://product.kyobobook.co.kr/detail/S000000554505

HTTP & Network Basic | 우에노 센 - 교보문고

개발에 처음 입문했을 때부터 틈틈이 궁금한 부분만 찾아서 읽었던 책이다. 그 당시에는 책의 많은 부분이 잘 와닿지 않았는데, 실무를 하면 할수록 이 책에 등장하는 대부분의 용어를 매일같이 접하게 된다. 정처기 필기 준비하면서 익숙해진 용어들도 일부 있는데, 무심코 지나갔던 내용들을 이번 기회에 제대로 정리하고 넘어가기로 한다. 다만 http/2 내용이 없기 때문에, 1.1과 2 사양에 대한 내용은 별도 포스팅으로 분리해야겠다.

 

제 1장 웹과 네트워크의 기본에 대해 알아보자

• HTTP(HyperText Transfer Protocol): 클라이언트에서 서버까지 일련의 흐름을 결정하는 프로토콜
• 서로 통신을 하기 위해 필요한 규칙을 프로토콜이라 부른다.
• HTTP를 이해하기 위해서는 TCP/IP 프로토콜에 대해 이해가 필요한데, TCP/IP란 인터넷에 관련된 다양한 프로토콜 집합의 총칭
• TCP와 IP 프로토콜을 가리켜 TCP/IP라고 부르기도 하지만, IP 프로토콜을 사용한 통신에서 사용되고 있는 프로토콜을 총칭해서 TCP/IP라는 이름이 사용되고 있다.
• TCP/IP는 애플리케이션 계층, 트랜스포트 계층, 네트워크 계층, 링크 계층 이렇게 4 계층으로 나뉘어 있다.
• 계층화되어 있으면 사양이 변경된 계층만 바꾸면 되기 때문에 자유롭게 설계할 수 있다고 한다.
• 애플리케이션 계층은 유저에게 제공되는 애플리케이션에서 사용하는 통신의 움직임을 결정한다. (ex. HTTP, FTP, DNS)
• 트랜스포트 계층은 애플리케이션 계층에 네트워크로 접속되어 있는 2대의 컴퓨터 사이의 데이터 흐름을 제공한다. (ex. TCP, UDP)
• 네트워크 계층은 네크워크 상에서 패킷의 이동을 다룬다. 패킷이란 전송하는 데이터의 최소 단위이다.(ex. IP)
• 링크 계층은 네트워크에 접속하는 하드웨어 적인 면을 다룬다.
• TCP/IP로 통신을 할 때 계층을 순서대로 거쳐 상대와 통신하는데, 송신하는 측은 애플리케이션 계층부터 내려가고, 수신하는 측은 애플리케이션 계층으로 올라간다.
• IP와 IP 주소를 혼동하지 말자. IP(Internet Protocol)는 프로토콜의 명칭이다. 
• IP의 역할은 개개의 패킷을 상대방에게 전달하는 것인데, 전달하기까지 IP 주소와 MAC 주소(Madia Access Control Address)라는 요소가 중요하다.
• IP 주소는 각 노드에 부여된 주소를 가리키고, MAC 주소는 각 네트워크 카드에 할당된 고유의 주소이다. IP 주소는 변경이 가능하지만 기본적으로 MAC 주소는 변경할 수 없다.
• ARP(Address Resolution Protocol)는 주소를 해결(결정)하기 위한 프로토콜 중 하나인데, 수신지의 IP 주소를 바탕으로 MAC 주소를 조사할 수 있다.
• TCP(Transfer Control Protocol)는 신뢰성 있는 바이트 스트림 서비스(용량이 큰 데이터를 TCP 세그먼트라는 단위 패킷으로 작게 분해하여 관리하는 것)를 제공한다.
• 3 Way-Handshake란 상대에게 패킷을 보내고 바로 끝내는 것이 아니라, 보내졌는지 여부를 상대에게 확인한다. 'SYN', 'ACK'라는 TCP플래그를 사용한다. = 신뢰성 있는 서비스
• DNS(Domain Name System)은 HTTP와 같이 응용 계층 시스템에서 도메인 이름과 IP 주소 이름 확인을 제공한다.
• URI(Uniform Resource Identifiers)는 리소스를 식별하기 위해 문자열 전반을 나타내고, URL(Uniform Resource Location)은 리소스의 장소(네트워크 상의 위치)를 나타낸다. URL이 URI의 서브셋.
• URI는 스키마를 나타내는 리소스를 식별하기 위한 식별자
• 절대 URI 포맷
  • http://user:pass@www.example.jp:90/dir/index.htm?uid=1#ch1
  • 스키마 + 자격정보(크레덴셜) + 서버주소 + 서버포트 + 계층적파일패스 + 쿼리문자열 + 프래그먼트 식별자

 

제 2장. 간단한 프로토콜 HTTP

• HTTP는 상태를 유지하지 않는 stateless 프로토콜이다. 이전에 보냈던 리퀘스트나 이미 되돌려준 리스폰스에 대해서는 전혀 기억하지 않는다.
• 상태를 계속 유지하고 싶을 경우 쿠키(Cookie)를 사용한다.
• 서버에서 리스폰스로 보내진 Set-Cookie라는 헤더 필드에 의해 쿠키를 클라이언트에 보존하게 된다. 다음번에 클라이언트가 같은 서버로 리퀘스트를 보낼 때 자동으로 쿠키 값을 넣어서 송신한다.
• HTTP 메소드 정리:

메소드	설명	추가설명
GET	리소스 조회	쿼리스트링 등으로 요청, 서버 상태 변경 없음
POST	데이터 전송 및 생성	보통 폼 데이터나 JSON 바디 전송, 서버의 상태를 변경
PUT	리소스 전체 교체(업데이트)	특정 리소스를 통째로 덮어씀
PATCH	리소스 부분 수정	PUT은 전체 교체, PATCH는 일부 수정
DELETE	리소스 삭제	서버 리소스를 제거
HEAD	리소스의 헤더만 요청	GET과 같지만 본문 없음, 리소스 존재 여부 확인용
OPTIONS	서버가 지원하는 메소드 목록 조회	주로 CORS 사전 요청(preflight)에 활용됨
TRACE	요청이 서버까지 전달되는 경로 추적	클라이언트가 보낸 요청이 서버까지 가는 경로를 추적하고, 중간에 프록시 서버들이 요청을 어떻게 변경했는지 확인하는 디버깅 용도 (보안상 거의 비활성화)
CONNECT	프록시를 통한 터널 연결 요청	주로 HTTPS(TLS) 통신 시 프록시 터널 생성에 사용. 프록시 서버를 통해 TCP 터널을 만들어, 클라이언트와 목적지 서버 간 암호화된 통신(HTTPS)을 가능하게 함

 

제 3장. HTTP 정보는 HTTP 메시지에 있다

• HTTP에서 교환하는 정보는 HTTP 메시지라고 불린다. 복수 행(개행 문자는 CR+LF)의 데이터로 구성된 텍스트 문자열이다.
• HTTP 메시지는 크게 "메시지 헤더"와 "메시지 바디"로 구분되어 있고, 최초에 나타나는 개행 문자로 메시지 헤더와 메시지 바디를 구분한다.
• HTTP로 데이터를 전송할 때 인코딩(변환)을 실시함으로써 전송 효율을 높일 수 있다.
• 메시지 바디와 엔티티 바디의 차이
  • 메시지(Message): HTTP 통신의 기본 단위로 옥텟 시퀀스(Octet sequence, octet은 8비트)로 구성되고 통신을 통해서 전송된다.(-> 실제로 네트워크를 통해 전송되는 데이터. 엔티티 바디가 인코딩/압축된 형태일 수 있음)
  • 엔티티(Entity): Request와 Response의 페이로드(Payload, 부가물)로 전송되는 정보로, 엔티티 헤더 필드와 엔티티 바디로 구성된다.(-> 실제 전송하려는 원본 데이터)
  • HTTP 메시지 바디의 역할은 리퀘스트와 리스폰스에 관한 엔티티 바디를 운반하는 일이다. 기본적으로 메시지 바디와 엔티티 바디는 같지만 전송 인코딩(Transfer Encoding)이 적용된 경우에는 엔티티 바디의 내용이 변화하기 때문에 메시지 바디와 달라진다.(http/2 이상부터는 이 구분이 사라졌음)

• 콘텐츠 인코딩(Content Encoding)
  • 엔티티에 적용하는 인코딩을 의미하며, 엔티티 정보를 유지한 채로 압축한다. 이를 수신한 클라이언트 측에서 디코딩한다.
  • ex. gzip(GNU zip), compress(UNIX의 표준 압축), deflate(zlib), indentity(인코딩 없음)
• 전송 인코딩(Transfer Encoding)
  • 청크 전송 인코딩(Chunked Transfer Encoding)가 대표적
  • 엔티티 바디를 분할해서 전송함
  • +) http/2부터는 사용 금지됨. http/1.1에서만 사용 가능.
    • http/2부터는 바이너리 프레이밍으로 대체되어 Transfer-Encoding이라는 개념 자체가 불필요
    • 더 자세한 부분은 별도 http/2 포스팅으로
• MIME(Multipurpose Internet Extensions)는 텍스트, 영상, 이미지와 같은 여러 다른 데이터를 다루기 위한 기능으로, Content-Type이라는 헤더 필드에 데이터 종류를 나타낼 수 있다.
• Range 리퀘스트는 엔티티 범위를 지정해서 요청하는 것으로, 리스폰스는 상태 코드 206로 돌아온다.
• Content Negotiation이란 클라이언트와 서버가 제공하는 리소스의 내용에 대해서 교섭하는 것이다. 클라이언트에게 더 적합한 리소스를 제공하기 위함이며 언어와 문자 세트, 인코딩 방식을 기준으로 판단한다.

+) 책에는 Encoding이 아닌 Coding이라고 표현하지만, MDN 공식문서에서는 모두 영어로 Encoding이라고 되어있어서 이 부분을 Encoding이라고 작성함. 아마 본 책이 일본 기술서라서 번역 과정에서 이런 것 같다.

 

제 4장. 결과를 전달하는 HTTP 상태 코드

상태 코드 클래스:

	클래스	설명
1xx	Informational	리퀘스트를 받아들여 처리 중
2xx	Success	리퀘스트를 정상적으로 처리했음
3xx	Redirection	리퀘스트를 완료하기 위해 추가 동작 필요
4xx	Client Error	서버는 리퀘스트 이해 불가능
5xx	Server Error	서버는 리퀘스트 처리 실패

각 상태코드:

• 202 Accepted: 요청이 접수되었으나 아직 처리되지 않음 (비동기 처리)
• 204 No Content: 요청이 성공했으나 응답 본문이 없음 (주로 DELETE 요청에서 사용)
• 206 Partial Content: Range 요청에 대한 부분 응답
• 301 Moved Permanently: 영구적인 리다이렉션
  • 요청한 리소스가 새로운 URL(Location 헤더)로 영구적으로 이동했음을 알리고 리다이렉션
  • 단, 301은 어떤 메서드였든지 GET 메서드로 변경하고, 308은 HTTP 메서드 변경이 이루어지지 않음
• 302 Found: 임시적인 리다이렉션
  • 요청한 리소스가 다른 URL(Location 헤더)에 임시적으로 이동했음을 알리고 리다이렉션
  • 단, 302는 어떤 메서드였든지 GET 메서드로 변경하고, 307은 HTTP 메서드 변경이 이루어지지 않음
• 303 See Other: 다른 위치로 리다이렉션
  • POST 요청 후 GET으로 리다이렉션할 때 주로 사용 (PRG 패턴)
• 304 Not Modified: 캐시된 리소스 사용 가능
  • 리소스가 마지막 요청 이후 수정되지 않았음을 알림, 캐시된 복사본을 사용하도록 지시함
• 307 Temporary Redirect: 임시적인 리다이렉션
  • 요청한 리소스가 다른 URL(Location 헤더)에 임시적으로 이동했음을 알리고 리다이렉션
  • 단, 302는 어떤 메서드였든지 GET 메서드로 변경하고, 307은 HTTP 메서드 변경이 이루어지지 않음
• 308 Permanent Redirect: 영구적인 리다이렉션, 메서드 유지
  • 요청한 리소스가 새로운 URL(Location 헤더)로 영구적으로 이동했음을 알리고 리다이렉션
  • 단, 301은 어떤 메서드였든지 GET 메서드로 변경하고, 308은 HTTP 메서드 변경이 이루어지지 않음

• 401 Unauthorized: 인증 필요
  • 클라이언트가 인증되지 않았거나 유효한 인증 정보가 부족함
• 403 Forbidden: 권한 없음
• 404 Not Found: 리소스를 찾을 수 없음
  • 요청한 리소스가 서버에 존재하지 않음
• 405 Method Not Allowed: 허용되지 않는 메서드
  • 요청한 HTTP 메서드가 해당 리소스에서 지원되지 않음
• 408 Request Timeout: 요청 시간 초과
  • 클라이언트가 서버가 기다리는 시간 내에 요청을 완료하지 못함
• 409 Conflict: 리소스 충돌
  • 요청이 현재 서버 상태와 충돌함 (예: 중복된 사용자 등록)
• 413 Payload Too Large: 요청 본문이 너무 큼
  • 서버가 처리할 수 있는 크기를 초과함
• 415 Unsupported Media Type: 지원하지 않는 미디어 타입
  • Content-Type이 서버에서 지원되지 않음
• 429 Too Many Requests: 요청 횟수 제한 초과
  • Rate limiting에 걸림

• 500 Internal Server Error: 서버 내부 오류
  • 서버가 요청을 처리하는 과정에서 예상치 못한 오류 발생
• 501 Not Implemented: 구현되지 않음
  • 서버가 요청 메서드를 지원하지 않음
• 502 Bad Gateway: 게이트웨이 오류
  • 게이트웨이나 프록시 서버가 upstream 서버로부터 잘못된 응답을 받음
• 503 Service Unavailable: 서비스 이용 불가
  • 서버가 일시적으로 요청을 처리할 수 없음 (과부하, 유지보수 등)
• 504 Gateway Timeout: 게이트웨이 시간 초과
  • 게이트웨이나 프록시 서버가 upstream 서버로부터 시간 내에 응답을 받지 못함

 

제 5장 HTTP와 연계하는 웹 서버

• HTTP는 클라이언트와 서버 이외에 프록시, 게이트웨이, 터널과 같은 통신을 중계하는 프로그램과 서버를 연계하는 것도 가능하다.
• 프록시(Proxy): 서버와 클라이언트의 양쪽 역할을 하는 중계 프로그램으로, 클라이언트로부터 받은 리퀘스트 URI를 변경하지 않고 리소스 본체를 가진 서버(=오리진 서버)에 보낸다. 오리진 서버로부터 되돌아온 리스폰스는 프록시 서버를 경유해서 클라이언트에 돌아온다.
  • HTTP 통신 중 프록시 서버를 여러 대 경유하는 것도 가능하다. 
  • 프록시 서버를 경유해서 리퀘스트와 리스폰스를 릴레이 할 때마다 "via" 헤더 필드에 경유한 호스트 정보를 추가한다.
  • 캐싱 프록시: 프록시 서버상에 리소스 캐시를 보존해 주는 타입의 프록시이다. 프록시에 같은 리소스 리퀘스트가 온 경우, 오리진 서버로부터 리소스를 획득하는 것이 아니라 캐시를 리스폰스로서 되돌려 주는 것이다.
  • 투명 프록시: 프록시로 리퀘스트와 리스폰스를 중계할 때 메세지를 변경하지 않는 타입이다.
• 게이트웨이(Gateway): HTTP 서버 이외의 서버를 중계하는 서버로, 클라이언트로부터 수신한 리퀘스트를 리소스를 보유한 서버인 것처럼 수신한다.
  • 클라이언트와 게이트웨이 사이를 암호화하는 등으로 안전하게 접속함으로써 통신의 안전성을 높이는 역할을 함
  • (외부 시스템과의 연결 통로 같은 역할)
  • 내부 서버와 외부 시스템(DB, 결제 API 등) 간의 안전한 데이터 교환이나 서비스 연동 시 사용
• 터널(Tunnel): 서로 떨어진 두 대의 클라이언트와 서버 사이를 중계하며 접속을 주선하는 중계 프로그램
• 캐시(Cache)는 프록시 서버와 클라이언트의 로컬 디스크에 보관된 리소스의 사본을 가리킨다.

 

제 6장 HTTP 헤더

HTTP 헤더 필드에 대한 내용은 분량이 많아서 공식 문서로 대체

https://developer.mozilla.org/ko/docs/Web/HTTP/Reference/Headers

HTTP 헤더 - HTTP | MDN

• Cache-Control: 캐싱 동작을 지정하는 헤더
  • ex. Cache-Control: private, max-age=0, no-cache
  • https://developer.mozilla.org/ko/docs/Web/HTTP/Reference/Headers/Cache-Control
• [Req] Accept: 클라이언트가 처리할 수 있는 미디어 타입(MIME)
• [Req] Authorization: 클라이언트의 인증 정보(크리덴셜 값)을 전달하기 위해 사용
  • ex. Authorization: Bearer <token> 또는 Authorization: Basic <base64>
• [Req] Host: 리퀘스트한 리소스의 인터넷 호스트와 포트번호
• [Req] Content-Type: 요청 본문의 미디어 타입 지정
• [Req] Referer: 현재 요청을 보낸 페이지의 URI (HTTP 표준에서 Referrer를 Referer로 표기)
• [Req] User-Agent: 리퀘스트를 생성한 브라우저와 유저 에이전트의 이름 등을 전달
• [Req] If-Match: 조건부 리퀘스트. ETag와 함께 사용함. ETag 값과 일치하는 리소스만 받을 수 있음
• [Req] If-None-match: If-Match와 반대로 동작
• [Req] Range: 리소스의 일부만 요청 (부분 다운로드)
• [Res] ETag: 특정 버전의 리소스를 식별하는 식별자
  • 강한 ETag: 엔티티가 아주 조금 다르더라도 반드시 변화함
  • 약한 ETag: 리소스가 같다는 것만 나타냄. "W/"가 앞에 붙음
  • 리소스의 내용이 변경되면 ETag 값도 변경됨
• [Res] Location: 리다이렉트 할 페이지의 URL
• [Res] Vary: 오리진 서버가 로컬 캐시를 사용하는 방법에 대한 지시를 프록시 서버에 전달함. 캐시를 컨트롤함.
  • 어떤 요청 헤더를 기준으로 캐시를 구분할지 지정하는 헤더
  • ex. Vary: Accept-Encoding는 압축 방식에 따라 다른 캐시를 사용
• Via: 클라이언스와 서버 간의 리퀘스트 혹은 리스폰스 메시지의 경로를 알기 위해 사용
• [Res] Set-Cookie 필드 속성
  • • Secure: HTTPS에서만 쿠키 전송
    • HttpOnly: JavaScript에서 쿠키 접근 불가 (XSS 방어)
    • SameSite: CSRF 공격 방지
      • Strict: 같은 사이트에서만 쿠키 전송
      • Lax: 일부 cross-site 요청에서 전송 (기본값)
      • None: 모든 경우에 전송 (Secure 필수)
    • Expires: 쿠키 만료 날짜
    • Max-Age: 쿠키 유효 시간
    • Domain: 쿠키가 전송될 도메인
    • Path: 쿠키가 전송될 경로
• [Req] Cookie: 서버가 Set-Cookie로 보내서 브라우저에 저장됐던 쿠키를 전송
• [Res] Content-Type: 응답 본문의 미디어 타입
• [Res] Content-Encoding: 응답 본문의 압축 방식
  • ex. Content-Encoding: gzip, br
• [Res] Access-Control-Allow-Origin: CORS에서 허용할 origin 지정
• [Res] Access-Control-Allow-Methods: CORS에서 허용할 HTTP 메서드
• [Res] Access-Control-Allow-Headers: CORS에서 허용할 요청 헤더
  • ex. Access-Control-Allow-Headers: Content-Type, Authorization
• [Res] Last-Modified: 리소스가 마지막으로 수정된 시간
• [Res] Content-Security-Policy (CSP): XSS 공격 방지를 위한 콘텐츠 보안 정책
• [Res] X-frame-option: 다른 웹사이트의 프레임에서 표시를 제어함
  • DENY, SAMEORIGIN
• [Res] X-XSS-Protection: 크로스 사이트 스크립팅(XSS) 대책으로서 브라우저의 XSS 보호 기능을 제어함
  • 0: XSS 필터 무효
  • 1: XSS 필터 유효

 

제 7장 웹을 안전하게 지켜주는 HTTPS

• HTTP는 아래와 같은 보안 취약점이 있다.
  1. 암호화 하는 기능은 없기 때문에 통신 전체가 암호화되지는 않는다. 즉 평문으로 HTTP메세지를 보내게 된다.
  2. TCP/IP 구조의 통신 내용은 전부 통신 경로의 도중에 엿볼 수 있다. (ex. WireShark 프로그램)
  3. 통신 상대를 확인하지 않기 때문에 클라이언트/서버 위장이 가능하다.
  4. 완전성을 증명할 수 없기 때문에 내용 변조가 가능하다.
• 위의 취약점에 대한 해결책으로 HTTPS 가 있다.
  1. HTTP + 암호화 + 인증 + 완전성 보호 = HTTPS
  2. HTTPS는 HTTP통신의 소켓 부분을 SSL(Secure Socket Layer)이나 TLS(Transport Layer Security)라는 프로토콜로 대체한다. 만약 SSL과 함께 사용한다면, HTTP는 SSL과 통신하고 SSL이 TCP와 통신하게 된다.
  3. 또, 애플리케이션 계층의 데이터를 송신할 때에는 MAC(Message Authentication Code)라고 부르는 메시지 다이제스트를 덧붙일 수도 있다. MAC을 이용해서 변조를 감지할 수 있어 완전성 보호를 실현할 수 있다.
  4. 하지만 평문 통신에 비해서 CPU나 메모리 등 리소스가 많이 필요하기 때문에 개인 정보등 민감한 정보를 다룰 때만 HTTPS에 의한 암호화 통신을 사용한다. 또한 증명서 구입을 위한 비용이 든다는 단점이 있다.

 

제 11장 웹 공격 기술