애플리케이션 계층의 대표 주자: HTTP 프로토콜 (7계층)

HTTP: https://en.wikipedia.org/wiki/HTTP

 

드디어 네트워크 여정의 최상단, 7계층 애플리케이션 계층(Application Layer)에 도착했습니다!

 

이전 장들에서 우리는 데이터가 어떻게 물리적인 선로를 타고(L1), 옆 컴퓨터까지 전달되고(L2), 다른 네트워크의 컴퓨터까지 경로를 찾아가고(L3), 최종적으로 특정 프로세스까지 신뢰성 있게 또는 빠르게 전달되는지(L4 - TCP/UDP) 배웠습니다.

 

이제는 이 모든 하위 계층의 서비스를 활용하여, 우리가 실제로 사용하는 애플리케이션(프로그램)들이 서로 어떻게 '대화'하는지 알아볼 차례입니다. 그중에서도 웹(World Wide Web) 세상을 가능하게 하는 핵심 프로토콜, HTTP(HyperText Transfer Protocol)에 대해 깊이 파고들어 보겠습니다.

 

기억하세요: HTTP와 같은 7계층 프로토콜은 하위 계층, 특히 4계층(TCP 또는 UDP)의 서비스를 기반으로 동작합니다. HTTP/1.1과 HTTP/2는 기본적으로 TCP를 사용하므로, 통신 시작 전에는 항상 3-Way Handshake 과정이 수반됩니다. (HTTP/3는 UDP 기반의 QUIC 프로토콜을 사용합니다. *QUIC도 추후 다룰 내용 입니다. HTTP 카테고리에서 다루게 될듯합니다.)

---

1. HTTP 프로토콜이란?

• HyperText Transfer Protocol: 이름 그대로 하이퍼텍스트(HyperText), 즉 링크(Hyperlink)를 통해 다른 문서나 리소스로 연결될 수 있는 형태의 정보(주로 웹 페이지)를 전송(Transfer)하기 위한 규약(Protocol)입니다.
  • HTTP가 탄생한 과정은 꽤 흥미롭다. 입자물리 연구소인 CERN에서 시작된 것도 인상적이고, 이 프로젝트에 오랜 시간 헌신한 팀 버너스리의 이야기도 매력적이다 (버너스리라는 팀이 아니라, 이름이 '팀 버너스리'이다). 시간이 된다면 위키백과나 관련 유튜브 영상을 찾아보는 걸 추천한다.
• 웹(WWW)의 핵심: 월드 와이드 웹(WWW)에서 클라이언트(웹 브라우저)와 서버(웹 서버) 간에 데이터를 주고받는 가장 기본적인 약속입니다. 오늘날 거의 모든 웹 애플리케이션 통신의 기반이 됩니다.
• 다양한 데이터 전송: 초기에는 HTML 문서 전송이 주 목적이었지만, 현재는 이미지, 동영상, 오디오, JSON, XML 등 거의 모든 종류의 데이터를 전송할 수 있습니다. 이는 MIME(Multipurpose Internet Mail Extensions) 타입을 이용해 데이터 종류를 명시하기 때문에 가능합니다.
  • MIME 타입이란? 원래 이메일에서 다양한 형식의 데이터를 포함시키기 위해 고안된 표준입니다. HTTP에서는 Content-Type 헤더를 통해 전송되는 데이터의 형식을 명시하는 데 사용됩니다. (예: text/html, image/jpeg, application/json)
• 주요 특징:
  • 요청/응답 (Request/Response) 모델: 클라이언트가 서버에게 요청(Request)을 보내면, 서버는 그 요청을 처리하고 응답(Response)을 보내는 방식으로 동작합니다.
  • 비연결성 (Connectionless - HTTP/1.0): 초기 HTTP/1.0에서는 요청 하나당 TCP 연결 하나를 맺고 응답 후 바로 끊는 방식이었습니다.
  • 무상태 (Stateless): 각 요청은 이전 요청과 독립적으로 처리됩니다. 서버는 기본적으로 클라이언트의 이전 상태를 기억하지 않습니다. (상태 유지는 쿠키, 세션 등을 이용)

---

2. HTTP 버전의 발전: 효율성을 향하여

• HTTP/1.0 (1996년): "하나 요청, 하나 연결"
  • 특징: 요청 하나를 보내고 응답을 받으면 TCP 연결을 바로 끊는(Non-Persistent) 단순한 방식.
  • 문제점: 웹 페이지는 HTML 외에도 CSS, JavaScript, 이미지 등 여러 리소스로 구성됩니다. 각 리소스를 받을 때마다 매번 TCP 3-Way Handshake를 반복해야 하므로 매우 비효율적이고 서버 부하가 컸습니다.
• HTTP/1.1 (1997년 ~ 현재 주류): "연결 재사용과 파이프라이닝"
  • 개선점: HTTP/1.0의 비효율성을 크게 개선했습니다.
    • 지속 연결 (Persistent Connection): 기본적으로 TCP 연결을 한 번 맺으면, 요청/응답 교환이 끝나도 바로 끊지 않고 일정 시간 동안 유지(Keep-Alive)합니다. 같은 클라이언트가 같은 서버에 여러 요청을 보낼 때 이 연결을 재사용하여 Handshake 오버헤드를 줄입니다. (Connection: keep-alive 헤더)
      • 기회가 된다면 keep-alive에 대해 더 자세한 글을 작성해보려고 한다. :)
    • 파이프라이닝 (Pipelining): 하나의 TCP 연결 위에서, 이전 요청에 대한 응답을 기다리지 않고 여러 요청을 연속해서 보낼 수 있는 기능. 이론적으로는 효율적이지만, HOL(Head-of-Line) Blocking 문제 등으로 실제 구현 및 활성화에는 제약이 많았습니다.
• (참고) HTTP/2 (2015년) & HTTP/3 (2022년): 성능을 더욱 향상시킨 차세대 프로토콜입니다. (HTTP/2: 다중화, 헤더 압축 등 / HTTP/3: UDP 기반 QUIC 프로토콜 사용, HOL 블로킹 개선 등)

[궁금할 수 있는 포인트 🤔 & 답변 ✅]

• Q: "HTTP/1.0에서 연결을 바로 끊는 방식의 문제점은 정확히 무엇인가요?"
• A: 웹 페이지 하나를 로딩하려면 수십 개의 리소스(HTML, CSS, JS, 이미지 등)가 필요할 수 있습니다. 각 리소스를 요청할 때마다 TCP 연결(3-Way Handshake)과 해제(4-Way Handshake)를 반복하면, 실제 데이터 전송 시간보다 연결 설정/해제에 드는 시간과 네트워크 자원 소모(오버헤드)가 훨씬 커져 로딩 속도가 매우 느려집니다.
• Q: "HTTP/1.1의 지속 연결(Keep-Alive)은 어떻게 동작하나요?"
• A: 클라이언트와 서버가 한 번 TCP 연결을 맺으면, 첫 번째 요청/응답 후에도 연결을 바로 끊지 않습니다. 클라이언트는 같은 연결을 통해 다음 요청을 보낼 수 있고, 서버도 같은 연결로 응답합니다. 일정 시간(Timeout) 동안 추가 요청이 없거나, 명시적인 연결 종료 요청(Connection: close 헤더)이 있을 때 연결이 해제됩니다. 이를 통해 Handshake 비용을 크게 절약할 수 있습니다.
• Q: "HTTP/1.1 파이프라이닝의 HOL(Head-of-Line) Blocking 문제는 무엇인가요?"
• A: 파이프라이닝은 여러 요청을 보내고 순서대로 응답을 받아야 합니다. 만약 첫 번째 요청에 대한 응답 처리가 서버에서 지연되면, 이미 도착했을 수도 있는 후속 요청들에 대한 응답들도 모두 대기해야 하는 현상이 발생합니다. 마치 줄의 맨 앞(Head-of-Line)이 막혀서 뒤가 전부 기다리는 것과 같다고 해서 HOL Blocking이라고 부릅니다. 이 문제 때문에 HTTP/1.1 파이프라이닝은 널리 활성화되지 못했고, HTTP/2의 다중화(Multiplexing) 기술로 해결되었습니다.

---

3. HTTP 요청 (Request) 메시지 구조

클라이언트가 서버에게 보내는 메시지입니다. 크게 네 부분으로 구성됩니다.

[Request Line] (시작 줄)
[Headers]      (헤더들)
[Empty Line]   (빈 줄 - 헤더의 끝을 알림)
[Body]         (본문 - 선택 사항)

1. Request Line (시작 줄): 요청의 가장 기본적인 정보를 담습니다.
   • GET /search?q=network HTTP/1.1
   • 구성: [HTTP 메서드] [Request Target(요청 대상)] [HTTP 버전]
   • HTTP 메서드 (Method): 클라이언트가 서버에게 요청하는 동작의 종류를 나타냅니다.
     • GET:
       • 리소스 조회 (가장 흔함).
       • 서버의 상태를 변경하지 않음 (Safe).
       • 여러 번 호출해도 같은 결과 (Idempotent).
       • 데이터는 주로 URI 쿼리 스트링으로 전달.
     • POST:
       • 데이터 전송 (주로 리소스 생성).
       • 서버 상태 변경 가능.
       • 여러 번 호출 시 다른 결과 발생 가능 (Not Idempotent).
       • 데이터는 Body에 담아 전달.
     • PUT:
       • 리소스 전체 수정 또는 생성 (덮어쓰기).
       • Idempotent.
       • 데이터는 Body에.
     • PATCH:
       • 리소스 부분 수정.
       • Idempotent 아닐 수 있음.
       • 데이터는 Body에.
     • DELETE:
       • 리소스 삭제.
       • Idempotent.
     • HEAD:
       • GET과 유사하나, 응답 Body 없이 헤더만 받음 (리소스 존재 여부, 메타데이터 확인용).
       • Safe, Idempotent.
     • OPTIONS:
       • 대상 리소스에 대해 가능한 통신 옵션(메서드 등) 요청.
       • Safe, Idempotent.
     • 왜 메서드를 나눴을까? 각 요청의 의미(Semantic)를 명확히 하고, 서버와 클라이언트(또는 중간 프록시)가 요청의 특성(안전성, 멱등성 등)을 이해하고 다르게 처리(캐싱, 재시도 등)할 수 있도록 하기 위함입니다.
     • GET vs POST 차이 (주요):
       • GET은 조회, POST는 처리/생성 목적.
       • GET은 데이터를 URL에 노출, 길이 제한 있음, 캐싱 가능.
       • POST는 데이터를 Body에 숨김, 길이 제한 적음, 캐싱 안 됨(보통).
     • 백엔드 개발자의 관점: 각 메서드의 의미에 맞게 API를 설계하고 구현해야 합니다. GET 요청이 서버 상태를 변경하게 하거나, 중요한 데이터를 GET의 쿼리 스트링으로 받는 것은 좋지 않습니다. 각 메서드의 안전성/멱등성 특성을 이해하고 API를 설계해야 합니다.
   • Request Target (요청 대상): 요청하는 리소스의 경로. 일반적으로 URI(Uniform Resource Identifier)의 일부(주로 path와 query)가 사용됩니다.
     • URL vs URI: URI는 리소스를 식별하는 통합된 방식이고, URL(Uniform Resource Locator)은 리소스의 위치를 나타내는 URI의 한 종류입니다. 우리가 흔히 쓰는 웹 주소는 URL입니다. HTTP 명세에서는 일반적으로 URI라는 용어를 사용합니다. (/search?q=network 부분)
   • HTTP 버전: 사용하는 HTTP 프로토콜 버전 (예: HTTP/1.1, HTTP/2).
2. Headers (헤더): 요청에 대한 부가 정보(메타데이터)를 이름: 값 형태로 전달합니다. 수십 가지 종류가 있습니다. (아래에서 자세히)
3. Empty Line (빈 줄): 헤더의 끝과 본문의 시작을 구분하는 역할. 반드시 필요합니다. (CRLF - \r\n)
4. Body (본문): 실제 전송할 데이터를 담는 부분. GET, HEAD, DELETE, OPTIONS 메서드에서는 보통 비어있고, POST, PUT, PATCH 등에서 사용됩니다. 데이터 형식은 Content-Type 헤더로 명시됩니다.

[궁금할 수 있는 포인트 🤔 & 답변 ✅]

• Q: "HTTP 메서드의 안전(Safe)과 멱등(Idempotent)은 무슨 뜻인가요?"
• A:
  • 안전 (Safe): 해당 메서드를 호출해도 서버의 리소스 상태가 변경되지 않음을 의미합니다 (예: GET, HEAD, OPTIONS). 서버는 안전한 메서드 요청에 대해 부작용(Side effect)이 없다고 가정할 수 있습니다.
  • 멱등 (Idempotent): 동일한 요청을 여러 번 보내도 서버의 상태가 한 번 보냈을 때와 동일하게 유지됨을 의미합니다 (예: GET, PUT, DELETE). 예를 들어, DELETE 요청을 여러 번 보내도 첫 번째 삭제 후에는 아무런 변화가 없습니다. POST는 보통 멱등하지 않습니다(여러 번 보내면 여러 개의 리소스가 생성될 수 있음). 멱등성은 네트워크 오류 등으로 인한 재시도 시 중요하게 고려됩니다.
• Q: "URI와 URL은 정확히 뭐가 다른 건가요?"
• A: URI(Uniform Resource Identifier)는 인터넷의 자원을 식별하는 통합된 방법을 의미하는 넓은 개념입니다. URL(Uniform Resource Locator)은 그 자원이 어디에 있는지 위치를 알려주는 URI의 한 종류입니다. URN(Uniform Resource Name)은 위치와 상관없이 자원의 이름 자체로 식별하는 URI의 다른 종류입니다. 우리가 웹에서 사용하는 http://... 형태의 주소는 리소스의 위치를 나타내므로 URL이며, 동시에 URI이기도 합니다. HTTP 명세에서는 좀 더 포괄적인 URI라는 용어를 사용하는 경향이 있습니다.
• Q: "Request Target에는 왜 전체 URL 대신 경로만 쓰나요?"
• A: 요청 메시지의 Host 헤더에 도메인 이름(호스트) 정보가 별도로 들어가기 때문입니다. Request Line에는 해당 호스트 내에서의 구체적인 리소스 경로만 적어 메시지 크기를 줄이고 명확성을 높입니다. (단, 프록시 서버에 요청할 때는 전체 URL을 사용하기도 합니다.)

---

4. HTTP 응답 (Response) 메시지 구조

서버가 클라이언트의 요청을 처리하고 보내는 메시지입니다. 요청 메시지와 유사한 구조를 가집니다.

[Status Line]  (상태 줄)
[Headers]      (헤더들)
[Empty Line]   (빈 줄 - 헤더의 끝을 알림)
[Body]         (본문 - 선택 사항)

1. Status Line (상태 줄): 응답의 전반적인 상태를 나타냅니다.
   • HTTP/1.1 200 OK
   • 구성: [HTTP 버전] [상태 코드] [상태 문구(Reason Phrase)]
   • HTTP 버전: 사용된 HTTP 프로토콜 버전.
   • 상태 코드 (Status Code): 요청 처리 결과를 나타내는 세 자리 숫자 코드. 매우 중요합니다!
     • 1xx (Informational): 요청을 받았으며 처리 중. (거의 사용 안 함)
     • 2xx (Successful): 요청 성공적으로 처리.
       • 200 OK: 요청 성공 (가장 일반적).
       • 201 Created: 요청 성공, 리소스 생성됨 (주로 POST, PUT 응답).
       • 204 No Content: 요청 성공, 응답 본문에 보낼 내용 없음.
     • 3xx (Redirection): 요청 완료를 위해 추가 동작 필요 (주로 다른 URI로 이동).
       • 301 Moved Permanently: 요청한 리소스의 URI 영구적으로 변경됨.
       • 302 Found: 일시적으로 다른 URI 사용 (과거 많이 쓰임).
       • 304 Not Modified: 리소스 변경되지 않았으므로 캐시된 버전 사용 가능.
     • 4xx (Client Error): 클라이언트 측 오류. 요청 자체에 문제가 있음.
       • 400 Bad Request: 잘못된 요청 문법 등.
       • 401 Unauthorized: 인증 필요.
       • 403 Forbidden: 접근 권한 없음.
       • 404 Not Found: 요청한 리소스 없음.
     • 5xx (Server Error): 서버 측 오류. 서버가 요청 처리에 실패함.
       • 500 Internal Server Error: 서버 내부 오류 (일반적인 오류).
       • 503 Service Unavailable: 서버 과부하 또는 점검 중.
   • 상태 문구 (Reason Phrase): 상태 코드를 사람이 이해하기 쉽게 설명하는 짧은 텍스트 (예: OK, Not Found). 상태 코드만으로 기계는 처리하므로, 이 문구는 부가적입니다.
2. Headers (헤더): 응답에 대한 부가 정보(메타데이터)를 이름: 값 형태로 전달.
3. Empty Line (빈 줄): 헤더와 본문 구분.
4. Body (본문): 실제 응답 데이터(HTML 문서, JSON 데이터, 이미지 파일 등)를 담는 부분. 성공적인 GET 요청의 경우 요청한 리소스가, 에러 응답의 경우 에러 정보가 포함될 수 있습니다. 204 No Content 등 일부 응답에는 본문이 없습니다.

[궁금할 수 있는 포인트 🤔 & 답변 ✅]

• Q: "상태 코드는 왜 이렇게 여러 종류가 있나요? 그냥 성공/실패만 알려주면 안 되나요?"
• A: 상태 코드를 세분화하면 클라이언트(브라우저, 다른 프로그램)나 개발자가 요청 처리 결과를 더 구체적으로 파악하고 그에 맞는 적절한 후속 조치를 취할 수 있습니다. 예를 들어, 301과 302는 둘 다 리다이렉션이지만 영구적인지 임시적인지에 따라 브라우저의 캐싱 동작 등이 달라집니다. 401과 403은 둘 다 접근 실패지만 인증 문제인지 권한 문제인지 구분하여 사용자에게 다른 안내를 할 수 있습니다.
• Q: "상태 문구는 꼭 'OK', 'Not Found'여야 하나요? 서버에서 바꿔도 되나요?"
• A: 상태 문구는 상태 코드에 대한 부가적인 설명일 뿐, 프로토콜 처리 자체에는 영향을 주지 않습니다. 따라서 서버에서 임의의 문구로 변경해도 기술적으로 문제는 없습니다. 하지만 표준 문구를 사용하는 것이 일반적이며, 클라이언트나 중간 프록시가 특정 문구에 의존하는 비표준적인 구현이 있을 수도 있으므로 가급적 표준을 따르는 것이 좋습니다.

---

5. HTTP 헤더 (Header) 포맷 및 주요 헤더

헤더는 요청과 응답 모두에 포함될 수 있으며, 통신에 필요한 다양한 부가 정보를 전달합니다. 이름: 값 형태를 가집니다.

• 일반 헤더 (General Header): 요청/응답 메시지 모두에 적용될 수 있는 헤더 (메시지 전체에 대한 정보).
  • Date: 메시지가 생성된 일시.
  • Connection: 연결 상태 제어 (예: keep-alive, close).
• 요청 헤더 (Request Header): 요청 메시지에만 포함되며, 클라이언트 자신과 요청 자체에 대한 정보를 담음.
  • Host: 요청하는 서버의 도메인 이름(호스트명)과 포트 번호. HTTP/1.1부터는 필수 헤더입니다. 하나의 IP 주소로 여러 웹사이트를 운영하는 가상 호스팅(Virtual Hosting)을 가능하게 합니다. 서버는 이 헤더를 보고 어떤 웹사이트에 대한 요청인지 구분합니다.
  • User-Agent: 요청을 보낸 클라이언트(브라우저, 앱 등)의 정보. 서버는 이 정보를 보고 클라이언트에 맞는 응답을 주거나 통계 분석에 활용할 수 있습니다.
  • Accept: 클라이언트가 이해하고 처리할 수 있는 미디어 타입(MIME 타입) 목록.
  • Accept-Language: 클라이언트가 선호하는 자연 언어.
  • Authorization: 클라이언트 인증 정보 (예: Basic, Bearer).
  • Cookie: 서버로부터 이전에 발급받아 저장해 둔 쿠키 값. (상태 유지 목적)
• 응답 헤더 (Response Header): 응답 메시지에만 포함되며, 서버 자신과 응답 자체에 대한 정보를 담음.
  • Server: 응답을 보낸 웹 서버 소프트웨어의 정보.
  • Location: 리다이렉션(3xx 응답) 시 이동할 새로운 URI.
  • Allow: 해당 리소스에 대해 허용되는 HTTP 메서드 목록 (주로 405 응답에 포함).
  • Set-Cookie: 서버가 클라이언트에게 쿠키를 저장하도록 지시하는 헤더. (상태 유지 목적)
• 엔터티 헤더 (Entity Header - HTTP/1.1까지) / 표현 헤더 (Representation Header - 최신 명세): 메시지 본문(Body)에 포함된 콘텐츠 자체에 대한 정보. 요청/응답 모두 사용 가능.
  • Content-Type: 본문의 미디어 타입(MIME 타입)과 문자 인코딩 (예: text/html; charset=utf-8, application/json).
  • Content-Length: 본문의 크기(바이트 단위). 지속 연결에서 메시지 끝을 식별하는 데 중요.
  • Content-Encoding: 본문 데이터의 압축 방식 (예: gzip).
  • Cache-Control: 캐시 동작을 제어하는 지시문.

[궁금할 수 있는 포인트 🤔 & 답변 ✅]

• Q: "Host 헤더는 왜 HTTP/1.1부터 필수가 되었나요?"
• A: 인터넷이 발전하면서 하나의 서버(동일 IP 주소)에서 여러 개의 웹사이트(다른 도메인 이름)를 운영하는 가상 호스팅(Virtual Hosting)이 일반화되었습니다. 클라이언트가 IP 주소로 서버에 접속했을 때, 서버는 클라이언트가 어떤 도메인 이름으로 접속했는지 알아야 올바른 웹사이트 내용을 보여줄 수 있습니다. Host 헤더가 바로 이 도메인 이름 정보를 전달하는 역할을 하기 때문에 HTTP/1.1부터 필수가 되었습니다.
• Q: "쿠키(Cookie)와 셋쿠키(Set-Cookie)는 왜 필요한가요? HTTP는 무상태라면서요?"
• A: 네, HTTP 자체는 무상태(Stateless)입니다. 즉, 서버는 기본적으로 이전 요청을 기억하지 못합니다. 하지만 로그인 상태 유지, 장바구니 등 사용자의 상태를 유지해야 하는 경우가 많습니다. 이를 위해 서버는 Set-Cookie 응답 헤더를 통해 클라이언트(브라우저)에게 특정 정보(쿠키)를 저장하도록 지시합니다. 클라이언트는 이후 동일한 서버에 요청을 보낼 때마다 저장된 쿠키를 Cookie 요청 헤더에 담아 보냅니다. 서버는 이 쿠키를 보고 사용자를 식별하고 이전 상태를 파악하여 상태 유지가 가능한 것처럼 동작하게 됩니다. 즉, 쿠키는 무상태인 HTTP 위에서 상태를 유지하기 위한 방법입니다.
• Q: "Content-Length 헤더는 왜 중요한가요?"
• A: HTTP/1.1의 지속 연결(Persistent Connection) 환경에서는 하나의 TCP 연결을 통해 여러 요청/응답이 오고 갈 수 있습니다. 이때 수신 측은 어디까지가 현재 응답 메시지의 본문(Body)인지 정확히 알아야 다음 메시지를 처리할 수 있습니다. Content-Length 헤더는 본문의 길이를 명시해주어 메시지의 끝을 정확히 파악할 수 있게 해줍니다. (만약 길이가 가변적이거나 미리 알 수 없다면 Transfer-Encoding: chunked 헤더를 사용하기도 합니다.)

---

6. 실습: nc 와 curl 로 HTTP 직접 경험하기

• nc (netcat) 사용: 저수준 네트워크 연결 도구로, TCP 연결을 직접 맺고 HTTP 요청 메시지를 수동으로 입력해볼 수 있습니다.
  • nc www.google.com 80 (구글 서버 80번 포트에 TCP 연결)
  • 연결 후 직접 입력:

  • GET / HTTP/1.1
    Host: www.google.com
    Connection: close
    (Enter 키 두 번 입력하여 빈 줄 만들기)

  • 서버로부터 오는 응답 메시지(상태 줄, 헤더, 본문)를 직접 확인할 수 있습니다.
  • 느리게 치면 실패하는 이유?
    • 웹 서버는 불완전한 요청을 무한정 기다리지 않습니다. 일정 시간(Timeout) 내에 완전한 요청 메시지(특히 헤더 끝을 알리는 빈 줄까지)가 도착하지 않으면 연결을 끊어버릴 수 있습니다.
• curl 사용: HTTP 통신을 위한 강력한 커맨드 라인 도구. 요청 메시지 생성, 연결 관리, 응답 처리 등을 자동으로 수행해줍니다.
  • curl -v http://www.google.com (-v 옵션은 요청/응답 헤더 등 상세 정보 출력)
  • nc와의 차이점? nc는 단순히 TCP 연결 통로만 제공하고 사용자가 프로토콜 메시지를 직접 만들어야 하는 반면, curl은 HTTP 클라이언트로서 프로토콜의 세부 사항을 이해하고 처리해줍니다. 리다이렉션 자동 처리, HTTPS 지원, 쿠키 관리 등 다양한 기능을 제공하여 훨씬 편리합니다.

---

[마무리하며]

 

HTTP는 웹 통신의 근간을 이루는 중요한 애플리케이션 계층 프로토콜입니다. 요청/응답 모델을 기반으로 동작하며, 메서드, 상태 코드, 헤더 등 명확한 구조와 규칙을 가지고 있습니다. 특히 하위 계층인 TCP 위에서 동작하며, TCP의 신뢰성 있는 전송 서비스를 활용합니다. HTTP/1.0의 비효율성을 개선한 HTTP/1.1의 지속 연결 개념과, 데이터를 나누어 보내는 TCP 세그먼테이션과 IP 프래그먼테이션의 차이를 이해하는 것이 중요합니다. nc나 curl 같은 도구를 통해 직접 HTTP 통신을 경험해보면 더욱 깊이 있는 학습이 가능할 것입니다.