Network

네트워크 학습공간

최신업데이트 일자 : 2015. 09. 03
추가할 내용 : RFC 문서내용, 데이터통신과 컴퓨터 네트워크 및 기타 도서

용어정리

• Message Body와 Entity Body의 차이
  • messsage : HTTP 통신의 기본 단위로 옥텟 시퀀스(Octet sequence, octet은 8비트)로 구성되고 통신을 통해서 전송된다
  • entity : Request와 Response의 Payload로 전송되는 정보로 entity-header(header정보의) 와 entity-body로 구성된다

HTTP Method

• GET : 리소스 획득
• POST : 엔티티 전송
• PUT : 파일전송
• HEAD : 메세지 헤더 취득
• DELETE : 파일삭제
• OPTION : 제공하고 있는 메서드 문의
• TRACE : 경로조사
• CONNECT : 프록시에 터널링 요청

HTTP Message 구조

• Request (RFC2616-SEC5)
  • Message Header
    • request-line
    • general-header
    • request-header
    • entity-header
  • CRLF (new line)
  • Message Body
• Response (RFC2616-SEC6)
  • Message Header
    • status-line
    • general-header
    • request-header
    • entity-header
  • CRLF (new line)
  • Message Body

HTTP의 효율관리

• Content Coding
  • 엔티티에 적용하는 인코딩을 가리킨다. 엔티티 정보를 유지한채로 압축
  • 수신한 클라이언트 측에서 디코딩한다
  • 인코딩을 하면 다량의 액세스를 효율 좋게 처리할 수 있다. 단지 컴퓨터에서 인코딩 처리를 해야 하기 때문에 CPU등의 리소스는 보다 많이 소비하게 된다
• Chunk Transfer Coding
  • HTTP 통신에서는 요청했던 리소스 전부에 엔티티 바디의 전송이 완료되지 않으면 브라우저에 표시되지 않는다.
  • 사이즈가 큰 데이터를 전송하는 경우에 데이터를 분할해서 조금씩 표시할 수 있다
  • 이렇게 엔티티 바디를 분할하는 기능을 청크 전송 코딩이라고 부른다

Multipart

• 사전지식
  • 메일의 경우, 본문이나 복수의 첨부 파일을 붙여서 함께 보낼 수 있다
  • 이것은 MIME으로 불리는 메일로 텍스트나 영상, 이미지와 같은 여러다른 데이터를 다루기 위한 기능을 사용하고 있는 것이다.
    • MIME; Multipurpose Internet Mail Extensions
  • MIME은 1)이미지 등의 바이너리 데이터를 아스키 문자열에 인코딩하는 방법과 2)데이터 종류를 나타내는 방법 등을 규정하고 있다
• HTTP도 Multipart에 대응하고 있어 하나의 메시지 바디 내부에 엔티티를 여러개 포함시켜 보낼 수 있다
• 주로 이미지나 텍스트 파일 등을 업로드할 때 사용되고 있다
• 멀티파트의 종류 (둘다 boundary를 지정해서 Content를 구분해야 한다)
  • multipart/form-data : Web form으로부터 파일 업로드에 사용
  • multipart/byteranges : 상태코드 206(Partial Content) 리스폰스 메시지가 복수 범위의 내용을 포함하는 때 사용
• application/x-www-form-urlencoded와 multipart/form-data의 차이 (stackoverflow)
  • 전자는 하나의 쿼리스트링으로 데이터를 변환해서 전송한다. 데이터가 늘어날 수 있다
  • 후자는 각각의 데이터타입을 Content-Disposition항목을 통해 나타내므로 효율이 좋다

상태코드의 의미 (RFC-2616-SEC10)

• 첫번째 자리는 Response의 클래스를 의미, 나머지 2자리는 분류가 없다
• Infomational
  • 1XX = Request를 처리중이다
• Success
  • 2XX = Request를 정상적으로 처리했다
• Redirection
  • 3XX = Request를 완료하기 위해서 추가동작이 필요하다
• Client Error
  • 4XX = Request를 서버에서 이해할 수 없다
• Server Error
  • 5XX = Request를 처리하던 중 서버에서 실패하였다

대표적 상태코드 및 사용한 경험이 있는 종류

• 2XX
  • 200 OK
    • Request를 정상적으로 처리
  • 201 Created
    • Request를 통해 새로운 Resource를 생성
  • 204 No Content
    • Request를 통해 처리를 성공했지만 되돌려줄 리소스가 없다
  • 206 Partial Content
    • Range에 의해 서버에서는 지정된 범위의 GET Request를 받았음을 나타낸다
    • Response에는 Content-Range로 지정된 범위의 엔티티가 포함된다
• 3XX
  • 301 Moved Permanently
    • Request된 Resource에 새로운 URI가 부여되어 있기 때문에, 그 리소스를 참조하는 URI를 사용해야 한다는 것을 나타낸다
    • 북마크예시 : Resource URI가 변경되었으니, 변경해라
  • 302 Found
    • Request된 Resource에는 새로운 URI가 할당되어 있기 때문에 그 URI를 참조해 주길 바란다는 의미를 나타내고 있다
    • 301과 비슷하지만 302는 영구적인 이동이 아닌 일시적인 것이다.
  • 303 See Other
    • Request에 대한 리소스는 다른 URI에 있기 때문에 GET메소드를 사용해서 얻어야 한다는 것을 나타내고 있다.
    • 이것은 302와 같은 기능이지만, 리다이렉트 장소를 GET 메소드로 얻어야 한다고 명확하게 되어 있는 점이 302와 다르다
    • 예를들면 POST 메소드로 액세스한 CGI 프로그램을 실행한 후에 처리 결과를 별도의 URI에 GET 메소드로 리다이렉트 시키고 싶은 경우 등에 303이 사용되고 있다.
  • 304 Not Modified
    • Client가 조건부 Request를 했을때 리소스에 대한 액세스는 허락하지만, 조건이 충족되지 않음을 표시한다
  • 307 Temporary Redirect
    • 302 Found와 같은 의미를 지니지만, 302의 경우에는 POST로부터 GET으로 치환이 금지되어 있는데도 불구하고 구현상 그와 같이 되어있지는 않다
    • 307에서는 브라우저 사양에 따라 POST에서 GET으로 치환을 하지 않는다
    • 브라우저마다 Response를 처리하는 동작이 다를 경우가 있다
• 4XX
  • 400 Bad Request
    • 클라이언트의 원인으로 에러가 발생했음을 나타낸다
    • Request 구문이 잘못되었음을 나타낸다.
  • 401 Unauthorized
    • 송신한 Request에 HTTP 인증 (Basic, Digest Authentication) 정보가 필요하다는 것을 나타낸다
    • 401을 포함한 Response를 되돌리는 경우에는 Request된 Resource에 적용되는 challenge를 포함한 WWW-Authenticate 헤더 필드를 포함할 필요가 있다
    • 브라우저에서 처음 401 Response를 받은 경우에는 인증을 위한 Dialog가 표시된다
  • 403 Forbidden
    • Request된 Resource의 Access가 거부되었음을 나타내고 있다
    • 서버측은 거부의 이류를 분명히 할 필요가 있는데, 이유를 명확하게 하는 경우에는 엔티티 바디에 기재해서 유저측에 표시한다
  • 404 Not Found
    • Request한 Resource가 서버상에 없다는 것을 나타낸다
• 5XX
  • 500 Internal Server Error
    • 서버에서 리퀘스트를 처리하는 도중에 에러가 발생하였음을 나타낸다
  • 503 Service Unavailable
    • 일시적으로 서버가 과부하 상태이거나 점검중이기 때문에 현재 Request를 처리할 수 없음을 나타내고 있다
    • 이 상태가 해소되기까지 시간이 걸리는 경우에는 Retry-After 헤더필드에 따라 클라이언트에 전달하는 것이 바람직하다

Content Negotiation

• 클라이언트와 서버가 제공하는 리소스의 내용에 대해서 교섭하는 과정이다
• 판단주체가 서버 혹은 클라이언트 둘중에 하나가 될 수 있다
  • Server-driven Negotiation
  • Agent-driven Negotiation
  • Transparent Negotiation (hibrid)
• 판단기준은 Request Message에 포함된 request-header field이다.
  • Accept
  • Accept-Charset
  • Accept-Encoding
  • Accept-Language
  • Content-Language

통신 중계 프로그램

• 프록시 (w3.org)
  • 서버와 클라이언트의 양쪽 역할을 하는 중계 프로그램으로, 클라이언트로부터의 리퀘스트를 서버에 전송하고, 서버로부터의 리스폰스를 클라이언트에 전송한다
  • 사용분류
    • Cashing Proxy
      • 프록시로 리스폰스를 중계하는 때에는 프록시 서버 상에 리소스 캐시를 보존해 두는 타입의 프록시
      • 같은 리소스에 리퀘스트가 온 경우, 오리진 서버로부터 리소스를 획득하는 것이 아니라 캐시를 리스폰스로서 되돌려주는 것이 있다
    • Transparent Proxy : 메세지를 변경하는지
      • 프록시로 리퀘스트와 리스폰스를 중계할 때 메세지 변경을 하지 않는 타입의 프록시
      • 반대로 메세지에 변경을 가하는 타입의 프록시를 비투과 프록시라고 한다
• 게이트웨이
  • 다른 서버를 중계하는 서버로, 클라이언트로부터 수신한 리퀘스트를 리소스를 보유한 서버인 것처럼 수신한다.
  • 클라이언트에서 게이트웨이를 지나 HTTP서버 이외의 서비스를 제공하는 서버가 된다. 즉 다른 프로토콜을 연결
  • 역할
    • 클라이언트와 게이트웨이 사이를 암호화하는 등으로 안전하게 접속함으로서 통신의 안전성을 높이는 역할
• 터널
  • 서로 떨어진 두대의 클라이언트와 서버 사이를 중계하며 접속을 주선하는 중계 프로그램

HTTP Header Field

• HTTP 메시지를 구성하는 요소의 하나
• 메세지 바디의 크기를 사용하고 있는 언어, 인증 정보 등을 브라우저나 서버에 제공하기 위해 사용되고 있다
• 구조
  • 헤더필드 명 : 필드 값
  • ex) Content-Type : text/html
  • ex) Keep-Alive: timeout=15, max=100 (이렇게 복수개 선언 가능)

• HTTP Header Field 종류
  • General Header Field
    • request, response에 모두 사용되는 필드
  • Request Header Field
    • 클라이언트에서 서브로 송신된 request message에 사용되는 헤더
    • request의 부가적 정보와 클라이언트의 정보, 리스폰스의 콘텐츠에 관한 우선 순위등을 부가한다
  • Response Header Field
    • 서버 측에서 클라이언트 측으로 송신한 리스폰스 메시지에 사용되는 헤더
    • response의 정보와 서버의 정보, 클라이엉ㄴ트의 추가 정보 요구 등을 부가한다
  • Entity Header Field
    • request message와 response message에 포함된 entity에 사용되는 헤더로 콘텐츠 갱신 시간 등의 엔티티에 관한 정보를 부가한다

• 헤더필드
  • HTTP/1.1에 정의된 헤더 필드에는 47종류가 있다
  • HTTP/1.1 이외에 헤더 필드 외에 RFC에 정의되어 폭넓게 사용되고 있는것도 있다
    • 이러한 비표준 헤더 필드는 RFC4229 HTTP Header Field Registrations에 정리되어 있다
    • 종류로는 Set-Cookie, Content-Disposition 등이 있다
• General Header Field
  • Cache-Control : 캐시동작 지정
  • Connection : 홉바이 홉 헤더, 커넥션 관리
    • 프록시에 더 이상 전송하지 않는 헤더 필드를 지정
      • GET / HTTP/1.1
      • Upgrade: HTTP/1.1
      • Connection: Upgrade
      • 프록시 서버에서 Upgrade와 Connection 필드를 삭제한다
    • 지속적 접속 관리
      • HTTP 1.1에서는 지속적 접속이 디폴트로 되어 있다 (Connection: Keep-Alive)
      • 서버에서 명시적으로 접속을 끊고 싶을 경우 (Connection: Close)
  • Date : 메세지 생성 날짜
  • Pragma : 메세지 제어 - HTTP/1.1보다 오래된 버전의 흔적으로 HTTP/1.0와의 후방 호환성만을 위해서 정의되어 있는 헤더 필드이다 - 지정할 수 있는 형식은 1개 뿐이다 (Pragma: no-cache)
  • Trailer : 메세지 끝에 있는 헤더의 일람 - 예를들어 Trailer : Expires 라고하면 바디 맨 마지막에 Expires: Tue, 20 ~~ 이런식으로 선언되어 있다
  • Transfer-Encoding : 메세지 바다의 전송 코딩형식 지정 - HTTP/1.1에서 전송코딩 형식으로 청크 전송만이 정의되어 있다 (Transfer-Encoding: chunked)
  • Upgrade : 다른 프로토콜로 업그레이드 요청 (“이 프로토콜을 사용하게 해주지 않을래?”)
  • Via : 프록시 서버에 관한 정보 (경유하는 프록시 정보들을 순차적으로 추가한다)
  • Warning : 에러 통지

• Request Header Field
  • Accept : 유저 에이전트가 처리 가능한 미디어 타입, 선언순서는 우선순위가 된다
    • 텍스트 파일 : text/html, text/plain, text/css …, application/xhtml+xml, application/xml …
    • 이미지 파일 : image/jpeg, image/gif, image/png …
    • 동영상 파일 : video/mpeg, video/quicktime…
    • 애플리케이션용 바이너리 : application/octet-stream, application/zip …
  • Accept-Charset : agent에서 처리할 수 있는 문자셋, (문자셋 우선 순위별로 선언)
  • Accept-Encoding : agent에서 처리할 수 있는 콘텐츠 코딩과 상대적 우선순위를 지정
    • ex) Accept-Encoding : gzip, deflate
    • gzip : 파일 압축 프로그램 gzip(GNU zip)에서 생성된 인코딩 포맷으로 32비트 CRC를 사용한다
    • compress : UNIX 파일 압축 프로그램 “compress”에 의해서 만들어진 인코딩 포맷
    • deflate : deflate 압축 알고리즘에 의해서 만들어진 인코딩 포맷을 조합
    • identity : 압축과 변형을 하지 않는 디폴트 인코딩 포맷
    • • : asterisk를 지정하면 와일드 카드로서 모든 인코딩 포맷을 가리킨다
  • Accept-Language : 언어 우선순위
  • Authorization : agent의 인증정보를 전달하기 위해서 사용된다.
  • Expect : 서버에 대한 특정 동작의 기대
  • From : 유저의 메일 주소
  • Host : request한 resource의 인터넷 호스트와 포트번호를 전달한다.
    • HTTP/1.1에서 유일한 필수 헤더 필드이다
    • 1대의 서버에서 복수의 도메인을 할당할 수 있는 가상 호스트의 구조와 매우 깊은 관련이 있다
  • if-xxx
    • 조건부 리퀘스트라고 부른다
    • 조건부 리퀘스트를 받은 서버는 조건에 맞는 경우에만 리퀘스트를 받는다
  • If-Match : 엔티티 태그의 비교
    • 서버상의 리소스를 특정하기 위해서 엔티티 태그(ETag) 값을 전달한다.
  • If-Modified-Since : 리소스의 갱신 시간 비교
  • If-None-Match : 엔티티 태그의 비교(If-Match의 반대)
  • If-Range : 리소스가 갱신되지 않은 경우에 엔티티의 바이트 범위의 요구를 송신
  • If-Unmodified-Since : 리소스가 갱신되지 않은 경우에 엔티티의 바이트 범위의 요구를 송신
  • Max-Forwards : 최대 전송 홉 수
  • Proxy-Authorization : 프록시 서버의 클라이언트 인증을 위한 정보
  • Range : 엔티티 바이트 범위 요구
  • Referer : request 중의 URI를 취득하는 곳
    • 기본적으로 Referer 헤더 필드는 보내져야 하지만, 브라우저의 주소창에 직접 URI를 입력한 경우와 보안상 바람직하지 않다고 판단된 경우에는 보내지 않아도 괜찮다.
    • 철자는 Referrer가 올바르지만, 잘못된 철자 그대로 사용되고 있다
  • TE : 전송 인코딩의 우선순위
  • User-Agent : HTTP 클라이언트의 정보
    • 로봇엔진의 request 의 경우에는 로봇 엔진의 책임자 메일 주소가 부가된 것도 있다.

• Response Header Field
  • Accept-Ranges : 바이트 단위의 요구를 수신할 수 있는지 없는지 여부
  • Age : 얼마나 오래 전에 오리진 서버에서 리스폰스가 생성되었는지를 전달한다.
    • 필드 값의 단위는 초이다.
    • 프록시가 리스폰스를 생성했다면 Age 헤더 필드는 필수이다
  • ETag : 리소스를 특정하기 위한 정보
    • entity tag라고 불리며, 서버는 리소스마다 ETag 값을 할당한다
    • 리소스가 갱신되면 ETag 값도 갱신할 필요가 있다
    • ETag 값의 문자에는 특별히 룰이 정해져 있지 않고 서버에 따라 다양한 ETag 값을 할당한다
  • Location : 클라이언트를 지정한 URI에 리다이렉트
  • Proxy-Authenticate : 프록시 서버의 클라이언트 인증을 위한 정보
  • Retry-After : Request 재시행의 타이밍 요구
  • Server : HTTP 서버 정보
  • Vary : 프록시 서버에 대한 캐시 관리 정보
  • WWW-Authenticate : 서버의 클라이언트 인증을 위한 정보

• Entity Header Field
  • Allow : 리소스가 제공하는 HTTP 메소드
  • Content-Encoding : 엔티티 바디에 적용되는 콘텐츠 인코딩
  • Content-Language : 엔티티의 자연어
  • Content-Length : 엔티티 바디의 사이즈 (단위 : 바이트)
  • Content-Location : 리소스에 대응하는 대체 URL
  • Content-MD5 : 엔티티 바디의 메시지 다이제스트
  • Content-Range : 엔티티 바디의 범위 위치
  • Content-Type : 엔티티 바디의 미디어 타입
  • Expires : 엔티티 바디의 유효기한 날짜
  • Last-Modified : 리소스의 최종 갱신 날짜

• 쿠키를 위한 헤더 필드
  • 쿠키는 HTTP 1.1의 사양인 RFC2616에 포함된 것은 아니지만 웹 사이트에서 널리 사용되고 있다
  • 쿠키는 유저식별과 상태관리에 사용되고 있는 기능이다.
  • 쿠키가 호출되었을 때는 쿠키의 유효 기한과 송신자의 도메인, 경로, 프로토콜 등을 체크하는 것이 가능하기 때문에, 적절하게 발행된 쿠키는 다른 웹 사이트와 공격자의 공격에 의해 데이터가 도난당하는 일은 없다.
  • 쿠키를 위한 헤더 필드
    • Set-Cookie : 서버에서 쿠키전송을 위한 response 헤더필드
      • 예시 : Set-Cookie: status-enable; expires=Tue, 05 Jul 2011 07:26:31 GMT; path=/; domain=.test.kr;
      • 필드속성
        • Name={Value} (쿠키에 부여된 이름과 값으로 필수이다)
        • Expires={DATE} (쿠키 유효기한으로 지정하지 않으면 브라우저를 닫을 때까지 이다)
        • Path={PATH} (쿠키 적용 대상이 되는 서버상의 디렉토리로 지정하지 않을 경우 도큐먼트와 같은 디렉토리가 된다. 이 지정을 피하는 방법이 있어서 보안효과는 기대할 수 없다)
        • Domain={도메인명} (예를들어 example.com로 지정했을 때 www.example.com이나 www2.example.com 등에서도 쿠키가 송출된다)
        • Secure (HTTPS로 통신하고 있는 경우에만 쿠키를 송신)
        • HttpOnly (쿠키를 Javascript에서 액세스하지 못하도록 제한)
    • Cookie : 서버에서 수신한 쿠키정보

• 이외의 헤더 필드
  • HTTP 헤더 필드는 독자적으로 확장할 수 있다.
  • 웹서버와 브라우저의 기능에 다양한 독자적 헤더필드가 존재한다
  • 그중에 자주 사용되는 헤더필드
  • X-Frame-Option
    • 다른 웹 사이트의 프레임에서 표시를 제어하는 HTTP Response Header로 Click jacking이라는 공격을 막는 것을 목적으로 한다.
    • 유효한 ㄴ브라우저는 익스8, 파폭3.6.9.+, 크롬 4.1+, 사파리4+, 오페라10.5+
    • 모든 웹 서버에서 설정해두는 것이 바람직하다
    • apache2.conf 설정의 예
      • <IfModule mod_headers.c>Header append X-FRAME-OPTIONS"SAMEORIGIN"<IfModule>
  • X-XSS-Protection
    • XSS의 대책으로서 브라우저의 XSS 보호 기능을 제어하는 HTTP Response Header
    • 0 : XSS 필터를 무효로 한다
    • 1 : XSS 필터를 유효로 한다
  • DNT
    • Do Not Track이라는 뜻이며 개인정보 수집을 거부하는 의사를 나타내는 HTTP Request Header이다.
    • 트래킹의 거부 의사를 나타내기 위한 방법 중 하나이다
    • 0 : 트래킹 동의
    • 1 : 트래킹 거부
    • 헤더 필드 기능이 유효성을 유지하기 위해서는 웹 서버에서 DNT를 지원해야 할 필요가 있다
  • P3P