[네트워크] HTTP

 

이번 시간에는 http에 대해서 알아 보겠습니다.

프로토콜 ?

http는 프로토콜 입니다. 그렇다면 프로토콜이 뭘까요 ? http를 공부하기 앞서 프로토콜에 대해 한번 생각해보고 가겠습니다.

위키백과에는 프로토콜을 다음과 같이 설명하고 있습니다.

 

"통신 프로토콜 또는 통신 규약은 컴퓨터나 원거리 통신 장비 사이에서 메시지를 주고 받는 양식과 규칙의 체계이다"

 

여기서 규약이라 함은 "서로 협의하여 정한 규칙"을 의미하는데, 두 장치간에 통신을 하는데 있어서의 "약속"입니다.

 

예를 들어서 우리가 미국에서 외국인들과 대화(통신)를 하는데 한국어를 사용하면 대화가 되지 않을 것입니다. 영어를 사용하는 미국에서 한국어를 사용하여 대화(통신)를 하는건 규칙, 약속에 어긋난 거죠. 이처럼 미국에서는 영어를, 한국에서는 한국어를 사용하는 것이 통상적으로 저희가 정한 규칙이죠. 여기서 이 규칙이 프로토콜 입니다.

 

사실 생각해보면 프로토콜은 우리에게 낯선 개념이 아닙니다. 택배를 보낼 때 받는 사람, 보내는 사람, 전화 번호, 주소 등의 정보를 기입할 것입니다. 이 내용들은 택배를 보내는데 반드시 필요한 정보겠죠. 상호간에 이런 정보들을 정한 규칙, 이것을 프로토콜이라고 합니다.

 

HTTP

HTTP(Hypertext Transfer Protocol) 인터넷상에서 데이터를 주고 받기 위한 서버/클라이언트를 따르는 프로토콜 이며, transport 계층의 tcp/ip 위에서 동작합니다.

 

HTTP는 어떤 종류의 데이터든지 전송할 수 있도록 설계되어 있습니다. 따라서 우리가 웹 브라우저를 통해서 보고 있는 html, css, 영상, 음악 등 모두 http를 기반으로 하고 있습니다.

 

---

HTTP 특징

 

1. connectless & stateless

HTTP는 connectless & stateless방식으로 동작합니다. 클라이언트가 서버에 어떤 자원을 요청하고 받으면 연결이 종료가 되는데 내가 A라는 사람을 만나서 얘기를 하고나서 내일 다시 그 A라는 친구와 얘기를 한다면 나를 처음본 사람 취급합니다. 이런 동작방식은 각각 아래의 장단점을 가집니다.

 

- 장점

불특정 다수를 대상으로 하는 서비스에 적합하다.

많은수의 사용자가 서비스를 사용하더라도 접속유지 시간을 최소한으로 할 수 있기 때문에 더 많은 사용자의 요청을 처리할 수 있다.

통신간의 연결 상태 처리나, 정보의 저장을 관리할 필요가 없어 설계가 간단하다.

각각의 독립된 http요청에 응답만 보내주면 된다.

 

- 단점

연결을 끊어 버리기 때문에 클라이언트의 이전 상태를 알 수 없다.

클라이언트가 과거에 로그인을 성공 하더라도 로그 정보를 유지할 수 없다 ㅡ> cookie를 사용하여 이 문제를 해결

 

2. Keep - alive

HTTP는 connectless & stateless 한 특징을 가지고 있습니다. 서버로부터 하나의 자원을 받으면 바로 연결을 끊어 버리죠. 그런데 만약 하나의 html파일 내부에 여러개의 css, js파일이 있으면 매번 css, js를 받을 때 마다 연결을 끊고 다시 연결해야 할까요 ?

 

이런 단점을 보완해주는 것이 Keep- alive이며 HTTP 1.1부터 나왔습니다. 이름에서 알 수 있는 것처럼 연결을 죽지 않고 살아 있는 상태를 유지 하는 기능을 지원하며 time out시간 내에 클라이언트가 재 요청을 하면 새로운 연결이 아니 기존에 연결되어 있는 것을 사용합니다.

 

---

HTTP 메소드

http 메소드는 클라이언트와 서버사이에 이루어지는 요청에 대해 클라이언트가 전송하는 자원에 대해 서버가 처리해주는 방식을 가리킨다. 쉽게 설명하면 클라이언트가 서버에게"get방식으로 처리해 주세요~" 라고 말하는 거죠.

 

1. GET : 데이터 취득

• URL(URI)형식으로 웹서버에 데이터를 요청
• 웹브라우저의 캐싱 기능에 도움을 줌, 최초 리소스를 요청할 때는 요청만 하고 이후 요청 때는 첫 요청의 응답에 함께 온 -http header정보를 참고하여 변경사항이 있는지 물어봄
• 캐싱에 중요한 http header :Last-Modified, eTag 등

 

2. POST : 데이터 전송

• 클라이언트에서 서버로 어떤 정보를 제출 함
• 요청 데이터를 http body에 담아 웹서버로 전송함
• 파일 전송 가능

 

3. PUT : 내용 갱신 위주

• POST처럼 정보를 서버로 제출하는 것으로 형식은 동일하나, 데이터 갱신 위주
• 파일 전송 가능

 

4. HEAD : 메세지 헤더 취득

• GET과 비슷하나, 실제 문서를 요청하는 것이 아니라 HTTP header정보만을 보냄(body 없이)

 

5. DELETE : 데이터 삭제 

• 서버에게 데이터 삭제를 요청

 

6. OPTIONS : 웹 서버측 제공 메소드에 대한 질의

• 가능한 메소드 옵션에 대한 질의
• 이 경우 응답메세지에 HTTP 헤더 항목 중, "Allow : GET, POST, HEAD" 처럼 보냄

 

7. CONNECT : 프락시 서버와 같은 서버 경유(거의 사용 안함)

 

8. TRACE : 요청 리소스가 수신되는 경로를 보여줌 (거의 사용 안함)

 

---

HTTP 공통헤더

HTTP 요청 및 응답 메시지 모두에서 사용 가능한 항목

 

- Date

HTTP 메시지를 생성한 일시 (RFC 1123에서 규정)
          Ex) Date: Sat, 2 Oct 2018 02:00:12 GMT

- Connection
클라이언트와 서버 간 연결에 대한 옵션 설정(다소 모호한 복잡성 있음)
         Ex) Connection: close

현재 HTTP 메시지 직후에 TCP 접속을 끊는다는 것을 알린다.
        Ex) Connection: Keep-Alive

현재 TCP 커넥션을 유지한다.

- Cache-Control
(쿠키/캐시 관련)

- Pragma

- Trailer

 

---

HTTP 엔티티 관련 헤더

HTTP 헤더 내 엔터티/개체 헤더 (Entity Header) 항목

 

요청 및 응답 메시지 모두에서 사용 가능한 Entity(콘텐츠, 본문, 리소스 등)에 대한 설명 헤더 항목

• HTTP 메시지는 이미지, 비디오, 오디오, HTML 문서, 전자메일 등의 개체들을 운반할 수 있다.
• HTTP 메시지 내 포함된 선택적인 개체에 대한 구체적인 미디어 타입 등의 설명

 

- Content-Type
해당 개체에 포함되는 미디어 타입 정보
컨텐츠의 타입(MIME 미디어 타입) 및 문자 인코딩 방식(EUC-KR,UTF-8 등)을 지정한다.
타입 및 서브타입(type/subtype)으로 구성된다.
          타입(type): 10개 정도 표준으로 지정됨(application, audio, font, image, multipart 등)
          서브타입(subtype): 각 타입별로 수십에서 수백개 정도
Ex) Content-Type: text/html; charset-latin-1
       해당 개체가 html 텍스트 문서이고, iso-latin-1 문자 인코딩 방식으로 표현되는 것을 의미한다.
(공통 헤더)

 

 

- Content-Language
해당 개체와 가장 잘 어울리는 사용자 언어(자연언어)
(공통 헤더)

 

- Content-Encoding
해당 개체 데이터의 압축 방식
Ex) Content-Encoding: gzip, deflate
만일 압축이 시행되었다면 Content-Encoding 및 Content-Length 2개 항목을 토대로 압축 해제가 가능하다.
(공통 헤더)

 

- Content-Length
전달되는 해당 개체의 바이트 길이 또는 크기(10진수)
응답 메시지 Body의 길이를 지정하거나 특정 지정된 개체의 길이를 지정한다.
(공통 헤더)

- Content-Location
해당 개체의 실제 위치를 알려준다.
(공통 헤더)

 

- Content-Disposition
응답 Body를 브라우저가 어떻게 표시해야할지 알려준다.
inline인 경우 웹페이지 화면에 표시되고, attachment인 경우 다운로드한다.
       Ex) Content-Disposition: inline
       Ex) Content-Disposition: attachment; filename='filename.csv'
다운로드되길 원하는 파일은 attachment로 값을 설정하고, filename 옵션으로 파일명까지 지정해줄 수 있다.
파일용 서버인 경우 이 태그를 자주 사용한다.
(응답 헤더)

 

- Content-Security-Policy
다른 외부 파일들을 불러오는 경우, 차단할 소스와 불러올 소스를 명시한다.
XSS 공격에 대한 방어 가능 (허용한 외부 소스만 지정 가능)
       Ex) Content-Security-Policy: default-src https:
               https를 통해서만 파일을 가져온다.
      Ex) Content-Security-Policy: default-src 'self'
             자신의 도메인의 파일들만 가져온다.
      Ex) Content-Security-Policy: default-src 'none'
            파일을 가져올 수 없다.
(응답 헤더)

 

- Location
리소스가 리다이렉트(redirect)된 때에 이동된 주소, 또는 새로 생성된 리소스 주소를 명시한다.
300번대 응답이나 201 Created 응답일 때 어느 페이지로 이동할지를 알려준다.
       새로 생성된 리소스의 경우
               - HTTP 상태 코드 201 Created가 반환된다.
       300번대 응답의 경우
              - HTTP/1.1 302 Found Location: /
              - 이런 응답이 왔다면 브라우저는 / 주소로 redirect한다.
(응답 헤더)

 

- Last-Modified
리소스를 마지막으로 갱신한 일시
(응답 헤더)

- Transfer-Encoding
chuncked
동적으로 생성되어 Body의 길이를 모르는 경우에 조금씩 전송이 가능하다.
각 chunk 마다 그 시작에 16진수 길이를 삽입하여 chunk 길이를 알려준다.
(응답 헤더)

 

---

HTTP 요청헤더

HTTP 헤더 내 요청 헤더 (Request Header) 항목HTTP 헤더 내 요청 헤더 (Request Header) 항목으로 요청 헤더는 HTTP 요청 메시지 내에서만 나타나며 가장 방대하다.

- Host
요청하는 호스트에 대한 호스트명 및 포트번호 (필수)
       - HTTP/1.1 이후부터 Host 필드는 필수 항목이다. (웹브라우저는 이를 반드시 포함해야 함)
Host 필드에 도메인명 및 호스트명 모두를 포함한 전체 URI(FQDN) 지정이 필요하다.
이에 따라 동일 IP 주소를 갖는 단일 서버에 여러 사이트를 구축할 수 있다.

 

- User-Agent
클라이언트 소프트웨어(브라우저, OS) 명칭 및 버전 정보

 

- From
클라이언트 사용자 메일 주소
         주로 검색엔진 웹 로봇의 연락처 메일 주소를 나타낸다.
         때로는, 이 연락처 메일 주소를 User-Agent 항목에 두는 경우도 있다.

 

- Cookie
서버에 의해 Set-Cookie로 클라이언트에게 설정된 쿠키 정보
(쿠키/캐시 관련)

- Referer
바로 직전에 머물었던 웹 링크 주소

- If-Modified-Since
제시한 일시 이후로만 변경된 리소스를 취득 요청

- Authorization
인증 토큰(JWT/Bearer 토큰)을 서버로 보낼 때 사용하는 헤더
“토큰의 종류(Basic, Bearer 등) + 실제 토큰 문자”를 전송

- Origin
서버로 POST 요청을 보낼 때, 요청이 어느 주소에서 시작되었는지 나타낸다.
여기서 요청을 보낸 주소와 받는 주소가 다르면 CORS 에러가 발생한다.
응답 헤더의 Access-Control-Allow-Origin와 관련

 

다음 4개는 주로 HTTP 메세지 Body의 속성 또는 내용 협상용 항목들

   - Accept
   클라이언트 자신이 원하는 미디어 타입 및 우선순위를 알린다.
           - 텍스트(text/html,text/plain,…),이미지(image/jpeg,…)     

   Ex) Accept: */*

           어떤 미디어 타입도 가능하다.
  Ex) Accept: image/*

              모든 이미지 유형이 가능하다.

 

   - Accept-Charset
         클라이언트 자신이 원하는 문자 집합

   - Accept-Encoding
   클라이언트 자신이 원하는 문자 인코딩 방식

   - Accept-Language
   클라이언트 자신이 원하는 가능한 언어
   각각이 HTTP Entity Header 항목 중에 Content-Type, Content-Type charset-xxx, Content-Encoding, Content-Language과    일대일로 대응된다.

---

HTTP 응답헤더

HTTP 헤더 내 응답 헤더 (Response Header) 항목HTTP 헤더 내 응답 헤더 (Response Header) 항목으로 특정 유형의 HTTP 요청이나 특정 HTTP 헤더를 수신했을 때, 이에 응답한다.

- Server
서버 소프트웨어 정보

- Accept-Range

- Set-Cookie
서버측에서 클라이언트에게 세션 쿠키 정보를 설정 (RFC 2965에서 규정)
(쿠키/캐시 관련)

- Expires
리소스가 지정된 일시까지 캐시로써 유효함을 나타낸다. 즉, 응답 컨텐츠가 언제 만료되는지를 나타낸다.
         Ex) Expires: Thu, 26 Jul 2018 07:28:00 GMT
Cache-Control과 별개로 응답에 Expires라는 헤더를 줄 수 있다.
       단, Cache-Control의 max-age가 있는 경우 이 헤더는 무시
(쿠키/캐시 관련)

- Age

캐시 응답. max-age 시간 내에서 얼마나 흘렀는지 초 단위로 알려준다.
(쿠키/캐시 관련)

- ETag
HTTP 컨텐츠가 바뀌었는지를 검사할 수 있는 태그
(쿠키/캐시 관련)

- Proxy-authenticate

- Allow
해당 엔터티에 대해 서버 측에서 지원 가능한 HTTP 메소드의 리스트를 나타낸다.
때론, HTTP 요청 메세지의 HTTP 메소드 OPTIONS에 대한 응답용 항목으로 사용된다.
        OPTIONS: 웹서버측 제공 HTTP 메소드에 대한 질의
Ex) Allow: GET,HEAD
      405 Method Not Allowed 에러와 함께
     웹 서버에서 제공 가능한 HTTP 메서드는 GET, HEAD 뿐임을 알린다.

- Access-Control-Allow-Origin
요청을 보내는 프론트 주소와 받는 백엔드 주소가 다르면 CORS 에러가 발생
       서버에서 이 헤더에 프론트 주소를 적어주어야 에러가 나지 않는다.
Ex) Access-Control-Allow-Origin: www.google.com
       프로토콜, 서브도메인, 도메인, 포트 중 하나만 달라도 CORS 에러가 난다.
Ex) Access-Control-Allow-Origin: *
       만약 주소를 일일이 지정하기 싫다면 *으로 모든 주소에 CORS 요청을 허용되지만 그만큼 보안이 취약해진다.
유사한 헤더로 Access-Control-Request-Method, Access-Control-Request-Headers, Access-Control-Allow-Methods, Access-Control-Allow-Headers 등이 있다.

 

---

HTTP 캐시/쿠키 관련 헤더

 

caching 관련

- Cache-Control
         Ex) Cache-Control: no-store
                  아무것도 캐싱하지 않는다.
          Ex) Cache-Control: no-cache
                  모든 캐시를 쓰기 전에 서버에 해당 캐시를 사용해도 되는지 확인한다.
          Ex) Cache-Control: must-revalidate
                  만료된 캐시만 서버에 확인을 받도록 한다.
          Ex) Cache-Control: public
                  공유 캐시(또는 중개 서버)에 저장해도 된다는 것을 의미한다.
          Ex) Cache-Control: private
                  브라우저같은 특정 사용자 환경에만 저장한다.
          Ex) Cache-Control: max-age
                  캐시 유효시간을 명시한다.

주로 응답 헤더로 사용하지만, “클라이언트 - 중개 서버 - 서버”의 구조에서 중개 서버의 캐시를 가져오지 않도록 하려면 클라이언트에서 요청 헤더에 이 헤더를 추가한다.
(공통 헤더)

- Expires
리소스가 지정된 일시까지 캐시로써 유효함을 나타낸다. 즉, 응답 컨텐츠가 언제 만료되는지를 나타낸다.
Ex) Expires: Thu, 26 Jul 2018 07:28:00 GMT
Cache-Control과 별개로 응답에 Expires라는 헤더를 줄 수 있다.
        단, Cache-Control의 max-age가 있는 경우 이 헤더는 무시
(응답 헤더)

- Age
캐시 응답. max-age 시간 내에서 얼마나 흘렀는지 초 단위로 알려준다.
Ex) max-age= 3600을 설정한 경우, 1분 후 Age: 60이 캐시 응답 헤더에 포함된다.
(응답 헤더)

- ETag
HTTP 컨텐츠가 바뀌었는지를 검사할 수 있는 태그
같은 주소의 자원이더라도 컨텐츠가 달라졌다면 ETag가 다르다.
같은 주소로 GET 메서드 수행 시 응답 Body의 내용이 동일하면 같은 ETag를 갖지만, 내용이 바뀌었다면 ETag 헤더 값이 변경된다.
이 헤더 값이 변경되었다면 캐시를 지우고 새로 변경된 컨텐츠를 받는다.
(응답 헤더)

- If-None-Match
서버에 ETag가 달라졌는지 검사를 요청한다.
ETag가 다를 경우에만 컨텐츠를 새로 받는다.
만약 ETag가 같다면 서버는 304 Not Modified를 응답해서 캐시를 그대로 사용한다.
(요청 헤더)

 

cookie 관련

- Cookie
서버에 의해 Set-Cookie로 클라이언트에게 설정된 쿠키 정보
Ex) Cookie: attribute1=value1; attribute2=value2;
서버는 이 쿠키 헤더를 파싱해서 사용한다.
CSRF 공격 같은 것을 막기 위해서 반드시 서버는 쿠키가 제대로 된 상황에서 온 것인지 확인하는 로직이 필요하다.
(요청 헤더)

 

- Set-Cookie
서버측에서 클라이언트에게 세션 쿠키 정보를 설정할 때 사용하는 항목 (RFC 2965에서 규정)
Ex) Set-Cookie: 속성이름(attribute)=속성값(value); 옵션들 형태로 다수 정보들이 설정됨
옵션들
      Expires
            쿠키 만료 날짜 설정
     Max-Age
           쿠키 수명 설정. Expires는 무시
     Secure
            https에서만 쿠키가 전송된다.
     HttpOnly
            자바스크립트에서 쿠키에 접근할 수 없다.
            XSS 요청을 막으려면 활성화해두는 것이 좋다.
     Domain
            도메인을 적어주면 도메인이 일치하는 요청에서만 쿠키가 전송된다.
            가끔 도메인이 다른 쿠키들이 있는데, 이런 쿠키들은 써드 파티 쿠키로 클라이언트를 추적하고 있는 쿠키이다.
     Path
           해당 path와 일치하는 요청에서만 쿠키가 전송된다.

 

Ex) Set-Cookie: pyh=apple; Expires=Wed, 21 Oct 2015 07:28:00 GMT; Secure; HttpOnly
    쿠키는 XSS 공격과 CSRF 공격 등에 취약하기 때문에 HttpOnly 옵션을 켜두고, 쿠키를 사용하는 요청은 서버 단에서 검증하는 쿠키는          XSS 공격과 CSRF 공격 등에 취약하기 때문에 HttpOnly 옵션을 켜두고, 쿠키를 사용하는 요청은 서버 단에서 검증하는 로직을 마련해두      는 것이 좋다.

(응답 헤더)