기사
시작
학습 시작
JavaRush /Java Blog /Random-KO /3부. HTTP/HTTPS 프로토콜
Professor Hans Noodles
레벨 41

3부. HTTP/HTTPS 프로토콜

Random-KO 그룹에 게시되었습니다
이 자료는 "엔터프라이즈 개발 소개" 시리즈의 일부입니다. 이전 기사: 안녕하세요! 오늘 우리는 HTTP와 HTTPS 프로토콜을 이해하겠습니다. 하지만 먼저 한 가지 점을 명확히 합시다. 우리는 OSI 모델의 애플리케이션 계층에서 네트워크를 통한 데이터 전송 프로토콜에 대해 이야기하고 있습니다. 기억하시겠지만, 이전 기사 중 하나에서 OSI 모델에 대해 논의했습니다. 기억나지 않는다면 여기 있습니다 . 3부. HTTP/HTTPS 프로토콜 - 1

데이터 전송 프로토콜이란 무엇입니까?

이는 다양한 서비스 개발자가 단일 형식으로 정보를 보내는 덕분에 일반적으로 허용되는 계약에 부여되는 이름입니다. 예를 들어 Google Chrome을 사용하면 개발자가 표준 HTTP 프로토콜을 사용하여 정보를 전송하고 브라우저가 이를 처리할 수 있기 때문에 Facebook과 Twitter 모두에서 정보를 얻을 수 있습니다. 통일된 규칙은 서버측 개발자 자신에게도 매우 편리합니다. 정보를 변환하고 필요한 프로토콜을 사용하여 전송할 수 있는 라이브러리가 많이 있습니다. HTTP는 원래 HTML 페이지를 전송하기 위한 프로토콜로 고안되었습니다. 오랫동안 이런 일이 있었지만 이제는 프로그래머가 문자열과 미디어 파일을 모두 전송하는 경우가 많습니다. 전반적으로 이 프로토콜은 다재다능하고 유연하며 사용하기가 정말 쉽습니다. 이제 이를 수행하는 방법을 알아봅시다.

HTTP 구조

HTTP 프로토콜이 텍스트로만 구성되어 있다는 점을 바로 주목할 가치가 있습니다. 글쎄, 우리는 이 텍스트가 위치한 구조에 가장 관심이 있습니다. 각 메시지는 세 부분으로 구성됩니다.
  1. 출발선 - 서비스 데이터를 정의합니다.
  2. 헤더 - 메시지 매개변수에 대한 설명입니다.
  3. 메시지 본문(Body) - 메시지 데이터입니다. 빈 줄로 제목과 구분해야 합니다.
HTTP 프로토콜을 사용하면 서버에 요청(request)을 보내고 서버로부터 응답(response)을 받을 수 있습니다. 요청과 응답의 매개변수는 약간 다릅니다.
Java-университет

간단한 HTTP 요청의 모습

GET / HTTP/1.1
Host: javarush.com
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.javarush.com/images/article/155cea79-acfd-4968-9361-ad585e939b82/original.pngsend?name1=value1&name2=value2 여기: javarush .com — 호스트, /send — 요청 경로, ? — 요청 매개변수가 뒤따른다는 것을 나타내는 구분 기호입니다. 마지막에는 매개변수가 앰퍼샌드로 구분된 key=value 형식으로 나열됩니다. POST - 서버에 정보를 게시합니다. POST 요청은 키=값 형식의 매개변수, JSON, HTML 코드, 파일 등 다양한 정보를 전송할 수 있습니다. 모든 정보는 메시지 본문으로 전송됩니다. 예를 들어: 
POST /user/create/json HTTP/1.1
Accept: application/json
Content-Type: application/json
Content-Length: 28
Host: javarush.com

{
  "Id": 12345,
  "User": "John"
}
요청은 javarush.com/user/create/json으로 전송되며 프로토콜 버전은 HTTP/1.1입니다. Accept는 클라이언트가 수신할 것으로 예상되는 응답 형식을 지정하고, 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 코드가 포함되어 있습니다.

응답 상태 코드

메시지 본문과 헤더를 보면 모든 것이 명확하지만 상태 코드에 대해 몇 마디 말씀드릴 가치가 있습니다. 응답 상태 코드는 항상 세 자리이며, 코드의 첫 번째 숫자는 응답 범주를 나타냅니다.
  • 1xx - 정보 제공용. 요청이 수신되었으며 서버는 계속할 준비가 되었습니다.
  • 2xx - 성공했습니다. 요청이 접수, 이해 및 처리되었습니다.
  • 3xx - 리디렉션. 요청을 처리하려면 다음 단계를 수행해야 합니다.
  • 4xx - 클라이언트 오류입니다. 요청에 오류가 있거나 프로토콜을 준수하지 않습니다.
  • 5xx - 서버 오류. 요청이 올바르게 구성되었음에도 불구하고 서버가 요청을 처리할 수 없습니다.
코드의 두 번째와 세 번째 숫자는 답을 자세히 설명합니다. 예를 들어:
  • 200 OK — 요청이 수신되어 성공적으로 처리되었습니다.
  • 201 생성됨 - 요청이 수신되어 성공적으로 처리되어 새 리소스 또는 해당 인스턴스가 생성되었습니다.
  • 301 영구적으로 이동됨 - 요청된 리소스가 영구적으로 이동되었으며 이에 대한 후속 요청은 새 주소에서 발생해야 합니다.
  • 307 임시 리디렉션 - 리소스가 일시적으로 이동되었습니다. 지금은 자동 리디렉션을 사용하여 액세스할 수 있습니다.
  • 403 금지됨 - 요청이 명확하지만 승인이 필요합니다.
  • 404 찾을 수 없음 - 서버가 이 주소에서 리소스를 찾지 못했습니다.
  • 501 구현되지 않음 - 서버가 이 요청에 응답하는 기능을 지원하지 않습니다.
  • 505 HTTP 버전이 지원되지 않음 - 서버가 지정된 HTTP 프로토콜 버전을 지원하지 않습니다.
응답 상태 코드 외에도 상태 설명도 전송되므로 특정 상태가 무엇을 의미하는지 직관적으로 이해할 수 있습니다. HTTP 프로토콜은 매우 실용적입니다. 이는 클라이언트와 서버 간의 유연한 통신을 설정할 수 있는 많은 수의 헤더를 제공합니다. 모든 요청 및 응답 헤더, 요청 방법 및 응답 상태 코드를 하나의 문서에서 고려할 수는 없습니다. 필요한 경우 모든 뉘앙스를 설명하는 공식 프로토콜 사양을 읽을 수 있습니다 . HTTP 프로토콜은 일반적으로 포트 80에서 사용되므로 포트 80에서 끝나는 주소를 보면 HTTP를 통해 액세스해야 한다는 것을 확신할 수 있습니다. 기술의 발전과 인터넷상의 개인 데이터의 활발한 이동으로 인해 우리는 클라이언트가 서버로 전송하는 정보에 대해 추가적인 보호를 제공하는 방법에 대해 고민해야 했습니다. 그 결과가 HTTPS 프로토콜이었습니다.

HTTPS와 HTTP의 차이점은 무엇입니까

HTTPS는 구문상 HTTP 프로토콜과 동일합니다. 즉, 동일한 시작 줄과 헤더를 사용합니다. 유일한 차이점은 추가 암호화와 기본 포트(443) 입니다 . HTTPS는 HTTP와 TCP 사이, 즉 애플리케이션과 전송 계층 사이에서 암호화됩니다. 그것이 무엇인지 잊었다면 OSI 모델에 관한 기사를 살펴보십시오 . 최신 암호화 표준은 TLS입니다. 이 주제에 대해 너무 깊이 다루지는 않겠지만 정보가 전송 계층에 도달하기 전에 암호화가 발생한다는 점을 기억하세요 . HTTPS는 요청이 전송되는 호스트와 포트를 제외한 모든 정보를 절대적으로 암호화합니다. HTTP 대신 HTTPS 프로토콜을 사용하도록 서버를 전환하기 위해 서버 코드를 변경할 필요가 없습니다. 이 기능은 서블릿 컨테이너에서 활성화되며, 이에 대해서는 다음 기사에서 설명하겠습니다. 오늘은 그게 다야. 하지만 잠깐만요. HTTP 요청을 감지하려면 Google Chrome을 열고 F12를 누른 후 네트워크 탭을 선택하세요. 귀하의 브라우저에서 보내거나 받은 모든 요청과 응답이 여기에 표시됩니다. 4부. Maven 기본 5부. 서블릿. 간단한 웹 애플리케이션 작성 6부. 서블릿 컨테이너 7부. MVC(모델-뷰-컨트롤러) 패턴 소개 8부. 작은 스프링 부트 애플리케이션 작성
코멘트
TO VIEW ALL COMMENTS OR TO MAKE A COMMENT,
GO TO FULL VERSION