CS/Newwork

Network : Web : HTTP/HTTPs

OSP 2024. 12. 27. 23:39

Network

Web

HTTP/HTTPs

HTTP

  • Hyper Text Transfer Protocol의 약자로, HyperText 즉 HTML(HyperText Markup language)를 주고 받을 목적으로 정의되었던 통신규약이다. 지금은 HTML만 주고받지는 않고 일반적인 프론트엔드 웹 리소스를 주고 받기 위해 사용된다.
  • 클라이언트-서버 구조의 Request-Response의 형식을 갖춘 Stateless Application level Protocol이다. HTTP포트를(TCP/80 또는 TCP/8080) 열고 대기중인 웹서버에 클라이언트가 요청하면, 서버가 이에 응답하여 클라이언트가 요청한 데이터를 제공하는 것이다.
  • HTTP/1.0, HTTP/1.1, HTTP/2, HTTP/3 버전이 있으며, 1.1가 가장 대중적이고 2로 넘어가려는 동향이다.
더보기
  • HTTP/1.0
    • 최초의 HTTP로, 1회적 연결을 특징으로 한다.
    • 무슨소리나면 1쌍의 요청과 응답을 주고 받으면 TCP연결을 끊어버린다. 
  • HTTP/1.1
    • 지속적인 연결을 지원하여(keep-alive) 하나의 TCP연결 위에 다수의 요청/응답 얹을 수 있게 한다.
    • 다만 요청과 응답을 병렬적으로 처리할 수는 없는 한계를 지닌다(RFC9112, 9.3.2 pipelining)
  • HTTP/2
    • 여러 요청과 응답을 병렬적으로 처리한다.(RFC9113, multiple concurrent exchange) 
  • HTTP/3
    • TCP대신 UDP에 기반하여 빠르게 통신한다.(QUIC : Quick UDP Internet Connections)

 HTTP 메세지

  • HTTP 메세지에는 Request/Response 둘 뿐이며, 모두 헤더와 바디로 구성된다.
  • HTTP 메세지는 0개 이상의 헤더를 포함할 수 있으며, 헤더와 바디는 빈 줄로 구분된다. 
    • Start Line : 최초 1행. 메세지의 핵심이 되는 뼈대이다(주어 동사)
    • Headers : CRLF 전의 모든 행. 메세지의 디테일한 설정들이다(형용사 부사)
    • Body : CRLF 후의 모든 행. 말 그대로 데이터의 몸체이다(목적어)
더보기
  • Start Line과 Header를 합쳐 Headers라고 한다. 영문표기상으로는 쉬이 구분되는 반면, 한국어로는 혼동을 피하기 위한 알잘딱깔쎈이 필요한 부분이다.
  • CRLF = CR(Carriage Return) + LF(Line Feed).
    • CR(\r)은 커서를 현재 줄의 맨 앞으로 이동시키는 문자이고, LF(\n)는 커서를 다음 줄로 이동시키는 제어문자이다. 윈도우 운영체제에서는 줄을 종결하기 위해 CRLF를 사용하고, 리눅스 등 유닉스 기반 운영체제에서는 LF만을 사용한다.
  • Start Line은 메소드/요청URI(경로)/따르는HTTP버전을 띄어쓰기로 구분해 표시한다.
    • GET 요청이기에 바디는 없다,
HTTP 요청 메세지 예시
GET /index.html HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/92.0.4515.159 Safari/537.36
Accept-Language: en-US,en;q=0.9
Connection: keep-alive
Header Content
Host 서버의 도메인 이름과 포트를 지정한다.
User-Agent 클라이언트측 브라우저/OS 정보를 포함한다.
Accept 클라이언트가 처리할 수 있는 미디어타입을 표시한다.
Accept-Language 클라이언트가 선호하는 언어를 표시한다.
Authorization 클라이언트가 서버에 인증 정보를 보낼 때 사용한다.
Cookie 클라이언트측에 저장된 쿠키 정보를 전달한다. 사용자인증/세션관리에 사용된다
  • 아래는 위 요청에 대한 HTTP 응답 메세지 예시이다
    • Start Line은 HTTP버전/상태코드/상태메세지를 띄어쓰기로 구분해 표시한다.
    • 헤더와 바디를 개행(CRLF, \r\n)으로 구분한다.
HTTP 응답 메세지 예시
HTTP/1.1 200 OK
Date: Fri, 28 Dec 2024 12:00:00 GMT
Server: Apache/2.4.41 (Ubuntu)
Content-Type: text/html; charset=UTF-8
Content-Length: 1256
Connection: keep-alive

<html>
  <head><title>Welcome to Example</title></head>
  <body>
    <h1>Welcome to Example!</h1> 
    <p>This is a sample page served by the server.</p>
  </body>
</html>
Header Content
Date 응답 생성 날짜/시간
Server 서버츠 소프트웨어
Content-Type 바디의 미디어타입(반환 데이터 유형)
Content-Length 바디의 길이(Byte)
Set-Cookie 서버가 클라이언트에게 제공하는 쿠키
Cache-Control 캐싱 동작 설정
Location 리다이렉션 응답에서 새로운 URL 지정
Access-Control-Allow-Origin CORS(Cross-Origin Resource Sharing) 정책을 설정하는 헤더. 도메인을 넘어서도 세션ID를 공유할 것인지 여부를 가린다.

 HTTP 메소드

  • 클라이언트측의 요청, 즉 서버에게 수행할 것을 요구하는 동작을 의미한다.
  • HTTP 표준에는 8개가 정의되어 있으며(RFC7231), GET(읽기)와 POST(쓰기)가 가장 대표적이다.
HTTP 메소드 동작
RFC 7231
표준		 GET 읽기
HEAD 읽기(헤더만)
POST 이어쓰기
PUT 덮어쓰기
DELETE 삭제하기
CONNECT 터널연결
OPTIONS 지원메소드 확인
TRACE 요청경로 추적
RFC 7231
비표준		 PATCH 수정(부분 덮어쓰기)
더보기
  • GET/HEAD
    • 서버 리소스 조회를 요청하는 메소드. 
      • HTML과 CSS, JS는 서로 별개의 리소스이기에 HTML을 제외한 외부 리소스는 별도의 GET 요청 메세지를 보내야 한다. 보통 브라우저가 HTML뿐만 아니라 CSS/JS등의 외부 리소스에 대한 GET요청 및 이후의 렌더링까지 처리하는 쾌적한 UX를 제공한다. 
      • 서버 리소스에 변화를 가져오지 않기 때문에 멱등적이다.
    • 특정 경로의 리소스를 요청할 수도 있고, 특정 쿼리에 부합하는 리소스를 요청할 수도 있다.
      • 클라이언트측에서 서버측의 모든 경로명/파라미터명을 알 수는 없다. 다만 이것저것 클릭하고 입력해보며 변하는 URL을 살펴봄으로써 어느정도 유추할 수는 있다. 요청데이터에 대한 정보가 URL에 노출되는 부분이 보안상 취약하기 때문에 로그인 정보 등은 POST메소드를 활용하는 것이 일반적이다.
    • HEAD는 GET과 달리 헤더만 요청한다는 점에서 다르고 나머지는 같다.
경로기반 GET 요청 메세지 예시
GET /user/123 HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)
Accept: application/json
Connection: keep-alive
쿼리기반 GET 요청 메세지 예시
GET /user?id=123
HTTP/1.1 Host: www.example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)
Accept: application/json
Connection: keep-alive
GET 응답 메세지 예시
  • POST
    • 서버에 새로운 리소스를 생성을 요청하는 메소드.
      • 서버 리소스를 변경하기 때문에 비멱등적이다.
      • 가입하기도 아니고 로그인이 POST메소드를 활용한다는 것은 어색할 수 있다. 일차적으로 로그인은 ID/PW 조회 및 입력값과의 대조 과정이지 무언가를 쓰는 과정은 아니기 때문이다. 실제로 과거에는 GET메소드로 로그인을 처리하는 경우가 다수였다. 그러나 URL 노출 문제로 현재느 대부분 POST 메소드로 로그인을 처리한다.
        1. GET 메소드는 요청 파라미터가 URL에 표시된다. OSP/OSP123!@#으로 로그인을 요청하면 URL에 "http://www.example.com/login?id=OSP&passwd=OSP123!@#"과 같이 표시되는 것이다.
        2. 반면 POST 메소드를 사용하면 ID/PW를 바디에서 처리할 수 있어 URL에 노출되는 것을 막을 수 있다.  
          • 로그아웃에도 POST 메소드를 사용하는데, 바디는 비어있다. GET는 서버 상태를 변경하지 않는 것으로 정의된 메소드라 부적절하고, POST는 서버 상태를 변경하는 것이니 상대적으로 적절하여 복잡하게 생각하지 않고 선택한 것으로 보인다. 자세한 시계열적 인과가 어찌 되는지 모르는 부분이긴 한데, 어차피 로그아웃 과정에서 POST요청 메세지는 보통 트리거 역할을 할 뿐고 메소드에 따라 크게 좌지우지 되지는 않는다. 
        3. 그러나 POST를 활용해도 body가 URL에 노출되지 않을 뿐이지 wireshark 따위의 패킷포획도구에 쉽게 노출되는 문제가 남는다. 왜냐하면 HTTP가 메세지를 암호화하지 않는 평문전송프로토콜이기 때문이다.
        4. 이에 등장한 기술이 HTTP메세지를 암호화하여 통신하는 HTTPs이다. 현재는 어지간한 웹페이지는 HTTPs를 채택한다.
    • 블로그포스팅은 사이트의(티스토리/네이버 등) 서버에 내가 작성한 글을 저장한다는 것이고, 나 또는 남의 블로그 글을 읽는 것은 그 서버에 저장된 리소스를 조회하는 것이다. 
POST 요청 메세지 예시 : 포스팅 POST 응답 메세지 예시 : 포스팅
POST /api/posts HTTP/1.1
Host: example.com
Content-Type: application/json
Content-Length: 71

 {
  "title": "Post Name",
  "content": "Post Content." 
}		 HTTP/1.1 201
Created Content-Type: application/json
Content-Length: 47

{
"status": "success",
"message": "Post created successfully",
"postId": 123
}
POST 요청 메세지 예시 : 인증 POST 응답 메세지 예시 : 인증
POST /login HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 45

username=OSP&password=OSP123!@#		 HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 29

{
"status": "success",
"message": "Login successful"
}
토큰/세션을 기반으로 HTTP의 stateless를 극복하기 전까지는 인증이 필요한 매 요청마다 새로이 인증을 요구했다. 로그인/로그아웃과 같은 상태 개념은 이러한 반복적 인증을 단순하게 치환하며 등장한 것이다. 
POST 요청 메세지 예시 : 로그인 : 토큰기반 POST 응답 메세지 예시 : 로그인 : 토큰기반
POST /login HTTP/1.1
Host: example.com
Content-Type: application/json

{
"username": "OSP",
password": "OSP123!@#"
}		 HTTP/1.1 200 OK
Content-Type: application/json

{
"token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.VQy-KYg7_m1Bkxu13klCVw4o-oMeNXFDePbkjrxRvn8"
}
POST 요청 메세지 예시 : 로그아웃 : 토큰기반 POST 응답 메세지 예시 : 로그아웃 : 토큰기반
POST /logout HTTP/1.1
Host: example.com
Authorization: Bearer <JWT_Token>
Content-Type: application/json		 HTTP/1.1 200 OK
Content-Type: application/json

{
"message": "Logout successful"
}
POST 요청 메세지 예시 : 로그인 : 세션기반 POST 응답 메세지 예시 : 로그인 : 세션기반
POST /login HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded

username=user&password=password123		 HTTP/1.1 200 OK
Set-Cookie: sessionid=abc123xyz;
Path=/; HttpOnly;
Secure Content-Type: application/json

{
"message": "Login successful"
}
POST 요청 메세지 예시 : 로그아웃 : 세션기반 POST 응답 메세지 예시 : 로그아웃 : 세션기반
POST /logout HTTP/1.1
Host: example.com
Cookie: sessionid=abc123xyz; Path=/; HttpOnly; Secure
Content -Type: application/json		 HTTP/1.1 200 OK
Set-Cookie: sessionid=; Path=/; HttpOnly; Secure; Expires=Thu, 01 Jan 1970 00:00:00 GMT
Content-Type: application/json

{
"message": "Logout successful"
}

상태코드/상태메세지

  • HTTP 응답 메세지의 Start Line에 위치하며, 요청에 대한 처리 상태를 표시한다.
  • RFC2616+@ 에서는 아래의 대략적인 맥락에서 약 40여개의 하위 상태 표준을 채택한다

상태코드 상태메세지 내용
1XX 처리중 요청 처리중
2XX 성공 요청 수락
3XX 리다이렉션 필요 처리를 위해 추가작업 필요
4XX 클라이언트사이드 에러 잘못된 요청으로 요청처리 불가
5XX 서버사이드 에러 서버측 오류로 요청처리 불가
6XX 사용자 정의 상태 -
더보기
  • 아래는 RFC2616에 기재된 표준 상태들이다.
    • 1XX는 통신이 계속되고 있는 임시 상태를 나타내는 코드로 최종 응답 이전의 중간 단계이다.
    • 2XX는 요청이 성공적으로 수락되었다는 최종 상태를 의미하는 코드로, 최종 응답이다.
    • 사문화된 코드가 대부분이고, 실제로 자주 사용되는 코드는 200-201/301-304/400-405 정도.
  상태코드 상태메세지 의미
요청 처리중 100 Continue 계속 요청 보내도 됨
101 Switching Protocols 유리한 프로토콜로 변환중이니까 대기 바람
요청 수락 200 OK 요청 데이터 반환함
201 Created 요청 데이터 생성함
202 Accepted 요청은 수락됐는데 아직 처리되지 않음
*HTTP외 방법으로 후속처리하는 경우
203 Non-Authoritative
Information		 요청 데이터 원본 대신 사본 반환
204 No Content 처리했는데 반환 데이터는 없음
205 Reset Content 처리했는데 너 새로고침 필요함
206 Partial Content 요청 데이터 부분만 반환함
리다이렉션 필요 300 Multiple Choices 여러 선택지가 존재함
301 Moved Permanently 리소스 위치 영구적으로 변경됨
302 Found 리소스 위치 임시적으로 변경됨
*기존 메소드를 유지할 수 있음
303 See Other 다른 URL에서 리소스 조회 필요함 
*GET 메소드를 사용해야함
304 Not Midified 수정되지 않은 리소스임
305 Use Proxy 프록시 써야 함
307 Temporary Redirection 리소스 위치 임시적으로 변경됨
*기존 메소드 유지해야 함
처리실패
클라이언트에러		 400 Bad Request 클라이언트 요청에 오류 있음
401 Unauthorized 인증이 필요한 사항인데 인증 없음
402 Payment Required 미래 사용을 위해 예약된 코드
403 Firbidden 클라이언트에게 권한이 없는 요청임
404 Not Found 요청한 리소스를 찾을 수 없음
405 Method Not Allowed 허용되지 않는 요청 메소드임.
406 Not Acceptable 요청에 적합한 리소스가 없음
*Accept 헤더 문제
407 Proxy Authentication
Required		 프록시 인증이 필요함
408 Request Timeout 요청시간 초과됨
409 Conflict 서버 상태와 충돌하는 요청임
410 Gone 리소스가 영구적으로 사라짐
411 Length Required Contetn-Length헤더가 필요한 요청임
412 Precondition Failed 하나 이상의 헤더에 문제 있음
413 Request Entity
Too Large		 요청 데이터가 너무 큼
414 Request URI
Too Long		 URL가 너무 김
415 Unsupported Media
Type		 지원되지 않는 미디어 타입임
416 Range Not Satisfiable Range 헤더에 문제 있음
417 Expectation Failed Expcet 헤더에 문제 있음
처리실패
서버에러		 500 Internal Server Error 서버 내부 오류로 처리 실패함
501 Not Implemented 서버에서 지원하지 않는 메소드임
502 Bad Gateway 서버측 게이트웨이/프록시에 오류 있음
503 Service Unavailable 과부하 등 유지보수 문제로 서비스 불가상태임
504 Gateway Timeout 서버측 게이트웨이/프록시 시간 초과됨
505 HTTP Version
Not Supported		 서버에서 지원하지 않는 HTTP버전임

Browser

 

  • 태초의 형태라면 우리는 웹서비스를 이용하기 위해 요청 메세지를 직접 입력하고, 응답 메세지를 직접 처리해야 한다. 이런 기술적인 작업의 많은 부분을 웹브라우저가 도맡아 하고 있으며, 우리에게 쾌적한 UX를 제공한다.
더보기
google.com에 GET 메소드를 보낸 경우의 응답 메세지이다. (curl의 디폴트 메소드는 GET이다) https://google.com으로 리다이렉션하라는 응답을 반환한다. HTTP 응답 자체는 여기서 끝이고 직접 curl https://www.google.com을 입력해야 한다.
리다이렉션 응답에 따라 curl https://www.google.com > GET_Google.html로 반환 데이터를 저장하여 열람한 모습. HTML만 온 것을 확인할 수 있다. 일반적으로 웹브라우저에서 출력되는 환경은 웹브라우저가 CSS/JS에 대한 별도 요청과 랜더링까지 처리한 이후의 환경이다.

HTTPs

  • GET에서는 요청파라미터가 URL에 노출되는 문제가 있었다. 그런데 HTTP메세지는 어차피 평문으로 전달되기 때문에 POST로 요청 파라미터를 Body에 숨기는 방법을 선택했음에도, 이 Body도 브라우저 표면에 노출되지 않을 뿐이지 쉽게 노출되는 것은 마찬가지였다.
  • 이러한 문제를 해결하기 위해 등장한 것이 HTTP메세지를 암호화해서 전달하는 HTTPs(HTTP + SSL/TLS)이다. 
  • 과거에는 민감한 데이터를 취급하는 웹서비스에서나 사용되었으나, 근래에는 디폴트가 HTTPs인 추세로, 와이어샤크로 예시를 보여줄 HTTP 사이트 찾기도 어렵다.

'CS > Newwork' 카테고리의 다른 글

네트워크 : 3. 네트워크 프로토콜  (1) 2024.12.20
네트워크 : 2. 네트워크 모델  (0) 2024.12.18
네트워크 : 1. 개념과 분류  (1) 2024.12.17

'CS/Newwork'의 다른글

  • 현재글Network : Web : HTTP/HTTPs

관련글

티스토리툴바