파트 3. HTTP/HTTPS

이 자료는 "엔터프라이즈 개발 소개" 시리즈의 일부입니다. 이전 기사:

안녕! 오늘 우리는 HTTP와 HTTPS 프로토콜에 대해 배울 것입니다. 하지만 먼저 한 가지 점을 분명히 하겠습니다. 우리는 OSI 모델의 애플리케이션 수준에서 네트워크를 통해 데이터를 전송하기 위한 프로토콜에 대해 이야기하고 있습니다. 이전 기사 중 하나에서 OSI 모델을 알게 된 것을 기억할 수 있습니다. 기억이 나지 않는다면 여기 있습니다 .

데이터 통신 프로토콜이란 무엇입니까?

이것은 서로 다른 서비스의 개발자가 다른 사람들이 이해할 수 있는 형식으로 정보를 보낼 수 있도록 하는 합의된 규칙 집합이라고 합니다. 예를 들어 개발자가 브라우저에서 처리할 수 있는 표준 HTTP 프로토콜을 사용하여 정보를 전송하기 때문에 Google 크롬을 사용하여 Facebook과 Twitter에서 정보를 가져올 수 있습니다. 균일한 규칙은 서버 부분을 개발하는 사람들에게 매우 편리합니다. 정보를 변환하고 적절한 프로토콜을 사용하여 보낼 수 있는 많은 라이브러리가 있습니다. HTTP는 처음에 HTML 페이지를 전송하기 위한 프로토콜로 인식되었습니다. 그것이 오랫동안 사용되었던 방식이지만, 지금은 프로그래머들이 문자열과 미디어 파일을 모두 보내는 데 자주 사용합니다. 일반적으로 이 프로토콜은 보편적으로 수용되고 다재다능하며 사용하기 정말 쉽습니다. 이제 우리는 그것을 사용하는 방법을 조사할 것입니다.

HTTP의 구조

HTTP 프로토콜은 텍스트로만 구성되어 있다는 점을 즉시 주목해야 합니다. 가장 흥미로운 것은 이 텍스트의 구조입니다. 각 메시지는 세 부분으로 구성됩니다.

시작 라인 — 일부 관리 데이터를 정의합니다.
헤더 - 메시지 매개변수를 설명합니다.
본문 — 메시지의 내용입니다. 본문은 빈 줄로 헤더와 구분되어야 합니다.

HTTP 프로토콜은 서버에 요청을 보내고 서버로부터 응답을 받는 데 사용됩니다. 요청과 응답의 매개변수는 약간 다릅니다.

간단한 HTTP 요청은 다음과 같습니다.

GET / HTTP/1.1
Host: codegym.cc
User-Agent: firefox/5.0 (Linux; Debian 5.0.8; en-US; rv:1.8.1.7)

시작 라인은 다음을 나타냅니다.

GET — 요청 방법
/ — 요청 경로
HTTP/1.1 — 프로토콜 버전

그런 다음 헤더를 가져옵니다.

호스트 — 요청이 전달되는 호스트
User-Agent — 요청을 보내는 클라이언트

메시지 본문이 없습니다. HTTP 요청에서는 시작 줄과 "Host" 헤더만 필요합니다. 이제 한 번에 한 단계씩 모든 것을 살펴보겠습니다. HTTP 요청에는 일부 메서드가 포함되어야 합니다. GET, POST, PUT, OPTIONS, HEAD, PATCH, DELETE, TRACE, CONNECT의 9가지가 있습니다. 가장 일반적인 것은 GET 및 POST입니다. 처음에는 이 두 가지 방법으로 충분합니다. GET — 이 메서드는 서버에서 콘텐츠를 요청합니다. 따라서 GET 메서드를 사용하는 요청에는 메시지 본문이 없습니다. 그러나 필요한 경우 다음 형식으로 경로(시작 줄)를 통해 매개 변수를 전달할 수 있습니다.

https://cdn.codegym.cc/images/article/155cea79-acfd-4968-9361-ad585e939b82/original.pngsend?name1=value1&name2=value2

여기서 codegym.cc 는 호스트이고 /send 는 요청의 경로이며 ? 쿼리 매개변수가 뒤따른다는 것을 나타내는 구분 기호입니다. 마지막에는 키-값 쌍("key=value")이 앰퍼샌드로 구분되어 나열됩니다. POST — 이 방법은 서버에 정보를 게시합니다. POST 요청은 "key=value" 쌍, JSON, HTML 코드 또는 파일과 같은 매개변수와 같은 다양한 종류의 정보를 보낼 수 있습니다. 모든 정보는 메시지 본문으로 전송됩니다. 예를 들어:

POST /user/create/json HTTP/1.1
Accept: application/json
Content-Type: application/json
Content-Length: 28
Host: codegym.cc

{
  "Id": 12345,
  "User": "John"
}

요청은 codegym.cc/user/create/json으로 전송되며 프로토콜 버전은 HTTP/1.1입니다. "수락"은 클라이언트가 받을 것으로 예상하는 응답 형식을 나타냅니다. "Content-Type"은 요청에서 보낸 메시지 본문의 형식을 나타냅니다. "Content-Length"는 본문의 문자 수입니다. HTTP 요청에는 다양한 헤더가 포함될 수 있습니다. 자세한 내용은 프로토콜 사양을 살펴보십시오 .

HTTP 응답

요청을 받은 후 서버는 이를 처리하고 클라이언트에 응답을 보냅니다.

HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Content-Length: 98

<html>
  <head>
    <title>An Example Page</title>
  </head>
  <body>
    <p>Hello World</p>
  </body>
</html>

응답의 시작 줄에는 프로토콜 버전(HTTP/1.1), 상태 코드(200) 및 상태 설명(OK)이 포함됩니다. 헤더에는 내용의 유형과 길이가 포함됩니다. 응답 본문에는 브라우저가 HTML 페이지로 렌더링하는 HTML 코드가 포함되어 있습니다.

응답 상태 코드

메시지 본문과 헤더에 관한 모든 것이 명확하지만 상태 코드에 대해 몇 마디 말해야 합니다. 응답 상태 코드는 항상 3자리입니다. 코드의 첫 번째 숫자는 응답 범주를 나타냅니다.

1xx — 정보용. 요청이 접수되었습니다. 서버는 계속할 준비가 되었습니다.
2xx — 성공. 요청이 접수, 이해 및 처리되었습니다.
3xx — 리디렉션. 요청을 처리하려면 추가 작업을 수행해야 합니다.
4xx - 클라이언트 오류. 요청에 오류가 있거나 프로토콜을 준수하지 않습니다.
5xx - 서버 오류. 요청이 올바르게 작성되었지만 서버에서 처리할 수 없습니다.

코드의 두 번째 및 세 번째 숫자는 보다 구체적인 응답을 나타냅니다. 예를 들어:

200 OK - 요청이 수신되어 성공적으로 처리되었습니다.
201 생성됨 - 요청이 수신되고 성공적으로 처리되어 새 리소스 또는 인스턴스가 생성되었습니다.
301 Moved Permanently — 요청된 리소스가 영구적으로 이동되었습니다. 이에 대한 후속 요청은 새 주소를 사용해야 합니다.
307 임시 리디렉션 — 리소스가 일시적으로 이동되었습니다. 지금은 자동 전달을 사용하여 액세스할 수 있습니다.
403 금지됨 — 요청이 이해되었지만 인증이 필요합니다.
404 찾을 수 없음 — 서버가 이 주소에서 리소스를 찾지 못했습니다.
501 Not Implemented — 서버가 요청에 응답하는 데 필요한 기능을 지원하지 않습니다.
505 HTTP 버전이 지원되지 않음 - 서버가 지정된 버전의 HTTP 프로토콜을 지원하지 않습니다.

응답 상태 코드 외에 상태 설명도 전송됩니다. 이것은 각각의 특정 상태가 의미하는 바를 명확히 하는 데 도움이 됩니다. HTTP 프로토콜은 매우 실용적입니다. 클라이언트와 서버 간의 매우 유연한 통신을 조정하는 데 사용할 수 있는 많은 수의 헤더를 제공합니다. 모든 요청 및 응답 헤더, 요청 방법 및 응답 상태 코드를 모두 고려하는 것은 단일 기사에 대해 너무 많은 것입니다. 필요한 경우 프로토콜의 공식 사양을 읽을 수 있습니다., 모든 뉘앙스를 설명합니다. 포트 80에서 HTTP 프로토콜을 사용하는 것이 일반적이므로 포트 80으로 끝나는 URL이 표시되면 HTTP를 사용하여 액세스해야 한다고 확신할 수 있습니다. 기술이 발전하고 개인 데이터가 인터넷을 통해 전송되기 시작하면서 클라이언트가 서버로 보내는 정보에 대한 추가 보호를 제공하는 방법에 대해 생각해야 했습니다. 이러한 생각의 결과가 HTTPS 프로토콜이었습니다.

HTTPS와 HTTP의 차이점

구문 측면에서 HTTPS는 HTTP 프로토콜과 동일합니다. 즉, 동일한 시작 라인과 헤더를 사용합니다. 유일한 차이점은 추가 암호화와 기본 포트(443) 입니다 . HTTPS는 HTTP와 TCP 사이, 즉 애플리케이션과 전송 계층 사이에서 암호화됩니다. 이것이 무엇을 의미하는지 잊었다면 OSI 모델에 대한 기사를 확인하십시오 . 오늘날의 암호화 표준은 TLS입니다. 이 주제를 너무 많이 다루지는 않겠지만 정보가 전송 계층에 도달하기 전에 암호화가 발생한다는 점을 기억하십시오.. HTTPS에서는 요청이 전송되는 호스트와 포트를 제외한 모든 정보가 절대적으로 암호화됩니다. HTTP 대신 HTTPS 프로토콜을 사용하도록 서버를 전환하면 서버 코드를 변경할 필요가 없습니다. 이 기능은 서블릿 컨테이너에서 활성화되며 후속 기사에서 논의할 것입니다. 오늘은 여기까지입니다. 사실, 잠시만요. 일부 HTTP 요청을 사용하려면 Google Chrome을 열고 F12를 누른 다음 "네트워크" 탭을 선택하십시오. 브라우저에서 보내거나 받은 모든 요청 및 응답이 여기에 표시됩니다. 파트 4. Maven의 기초 파트 5. 서블릿 및 Java 서블릿 API. 간단한 웹 애플리케이션 작성 6부. 서블릿 컨테이너 7부. MVC(Model-View-Controller) 패턴 소개