이 기사에서는 http 프로토콜의 프런트 엔드에 대한 몇 가지 상식 문제를 공유합니다. 관심 있는 친구는

http

HTTP 프로토콜 프런트엔드 상식

소개를 살펴보세요. http는 tcp/를 기반으로 데이터를 전송합니다. ip 통신

Notes

http는 연결이 없습니다. 각 연결은 하나의 요청만 처리합니다. 서버가 요청을 처리하고 클라이언트로부터 응답을 받은 후
http 미디어는 독립적입니다. 클라이언트와 서버는 데이터 유형을 처리하는 방법을 알고 있으며 모든 데이터는 http를 사용하여 전송될 수 있습니다.
http 무상태: 프로토콜에 트랜잭션 처리를 위한 메모리 기능이 없음을 의미합니다. 클라이언트 요청에는 요청 라인, 요청 헤더, 빈 라인 및 요청 데이터

2. http 응답: 상태 라인, 메시지 헤더, 빈 라인, 응답 본문

http 요청 방법 HTTP 프로토콜 프런트엔드 상식

http1.0 : get, post 및 head

method

descriptionInitiate a 특정 리소스에 요청공통 헤더 필드의 의미 소개헤더와 메소드가 함께 작동하여 클라이언트와 서버가 수행할 수 있는 작업을 결정합니다. 공통 헤더

	get
post	데이터 처리를 위해 지정된 리소스에 데이터를 제출합니다. 데이터는 요청 본문에 포함됩니다. 게시물 요청은 새 리소스를 생성하고 기존 리소스를 수정하는 데 사용될 수 있습니다.
head	는 반환 본문이 없다는 점을 제외하면 get 요청과 유사합니다. 응답 메시지에 포함된 헤더를 얻습니다.
put	최신 콘텐츠를 지정된 리소스에 업로드
delete	서버에 지정된 리소스를 삭제하도록 요청
trace	에코하세요. 주로 테스트 또는 진단을 위해 서버에서 수신한 요청
connect	http1.1은 연결을 파이프라인 방식으로 변경할 수 있는 프록시 서버용으로 예약되어 있습니다.
options	서버에서 지원하는 http 방식을 반환합니다. 특정 리소스에 대해 서버에 '*' 요청을 보내는 데 사용됩니다. 서버의 기능을 테스트하려면

클라이언트와 서버 모두에서 사용할 수 있습니다. 헤더

Header

Description을 사용하면 클라이언트와 서버가 요청/응답과 관련된 옵션을 지정할 수 있습니다. 그래요 연결

Connection

Date 은 날짜 및 시간 스탬프를 제공합니다. 메시지가 생성된 시기를 표시합니다.

MIME-Version 끝까지 전송된 MIME 버전을 제공

Trailer 메시지 전송에서 청크 분할을 사용하는 경우 전송 인코딩을 사용하면 이것을 사용할 수 있습니다. 헤더는 메시지의 트레일러 부분에 있는 헤더 세트를 나열합니다.

Transfer-Encoding 은 안정적인 전송을 보장하기 위해 메시지에 어떤 인코딩 방법이 사용되는지 수신자에게 알려줍니다. 메시지

Update 가 제공됩니다. 보낸 사람은 새 버전이나 프로토콜을 사용하기 위해 "업그레이드"할 수 있습니다

Via 메시지가 통과하는 중간 노드(에이전트, 게이트웨이)를 표시

요청 헤더

요청 메시지에 특별하며 클라이언트가 수신하기를 원하는 데이터 유형의 종류와 같은 몇 가지 추가 정보를 서버에 제공합니다.

요청의 정보 헤더

Header	설명
Client-Ip	클라이언트를 실행하는 컴퓨터의 IP 주소를 제공
From	클라이언트 사용자의 이메일 주소를 제공
Host	의 주소와 포트 번호 제공 요청을 받은 서버
Referer	현재 요청된 URL이 포함된 문서의 URL 제공
UA-color	클라이언트 모니터의 디스플레이 색상에 대한 정보 제공
UA-CPU	클라이언트 CPU 유형을 제공하고 제조업체
UA-Disp	는 클라이언트 디스플레이 기능에 대한 정보를 제공합니다.
UA-OS	은 클라이언트 시스템에서 실행되는 운영 체제와 버전을 제공합니다
UA-Pixels	클라이언트 디스플레이의 픽셀 정보를 제공합니다.
User-Agent	서버에 요청을 보내는 애플리케이션의 이름을 알립니다

헤더 수락

header	Description
Accept	서버에 보낼 수 있는 미디어 유형을 알려주세요
Accept-Charset	서버에 보낼 수 있는 문자 집합을 알려주세요
Accept-Encoding	서버에 어떤 미디어 유형을 알려주세요 보낼 수 있는 인코딩 방법
Accept-Language	은 서버가 보낼 수 있는 언어를 알려줍니다.
TE	어떤 확장 전송 인코딩을 사용할 수 있는지 서버에 알려줍니다.

조건부 요청 헤더

If-MatchIf-Modify-SinceIf-None-MatchIf-RangeIf-Unmodified-SinceRange보안 요청은 헤더

Header	Description
Allow client columns 요청에 필요한 서버 동작
엔터티 태그가 문서의 현재 엔터티 태그와 일치하는 경우 , 문서 가져오기
지정된 날짜 이후에 리소스가 수정되지 않은 경우, 그렇지 않으면 이 요청을 제한하세요.
엔터티 태그가 일치하지 않는 경우 문서의 현재 엔터티, 문서 가져오기
문서 변경 허용 범위 조건부 요청
리소스가 특정 날짜 이후에 수정되지 않은 경우 제외 그렇지 않으면 이 요청을 제한하세요
서버가 범위 요청을 지원하는 경우 리소스의 지정된 범위

에 의해 제어됩니다. 헤더 Authorization CookieCookie2프록시 요청 헤더

describes
에는 클라이언트가 자신을 인증하기 위해 서버에 제공한 데이터가 포함되어 있습니다.
클라이언트는 이를 사용하여 서버에 토큰을 보냅니다. 이는 실제 보안 헤더가 아닙니다. 보안 기능을 암시합니다
는 요청자가 지원하는 쿠키 버전을 나타내는 데 사용됩니다

HeaderMax-Forward Proxy-AuthorizationProxy-Connection 프록시와 연결을 설정할 때 사용됩니다.

응답 헤더

응답 메시지에는 클라이언트에 정보를 제공하기 위한 자체 헤더 세트가 있습니다. (처음부터 생성 시작) 응답 기간

Publick

Description
요청이 서버 경로의 다른 프록시 또는 게이트웨이로 전달되는 최대 횟수———— TARCE 방법과 함께 사용됩니다.
Authorization 헤더와 동일하지만 이 헤더는 프록시로 인증할 때 사용됩니다.
Connection 헤더와 동일하지만 이 헤더는 프록시로 인증할 때 사용됩니다.

서버에서 해당 리소스에 대해 지원하는 요청 방법 목록 리소스를 사용할 수 없는 경우 이 날짜 또는 시간에 다시 시도 협상 헤더이 리소스에 대해 서버에서 허용하는 데이터 유형

	Retry-After
Server	서버 응용 프로그램의 이름과 버전
Title	HTML 문서의 경우 HTML 문서의 소스에서 부여한 제목입니다
Wraning	이유문 텍스트보다 더 자세한 경고 보고서

Header	Description
	Accept-Ranges

다양함 서버 보기 기타 헤더 목록은 다음과 같습니다. 응답을 변경합니다. 즉, 이것은 헤더 목록이며 서버는 이러한 헤더의 내용을 기반으로 가장 적절한 리소스 버전을 선택하여 클라이언트에 보냅니다보안 응답 헤더프록시에서 클라이언트로의 쿼리 목록


Header	Description
	Proxy-Authenticate

Set-Cookie은 실제 보안 헤더는 아니지만 보안 기능을 의미합니다. 서버를 통해 클라이언트에 서명하려면 클라이언트 보안 토큰에 설정하세요Set-Cookie와 유사 엔티티 헤더 엔티티 헤더는 엔티티 바디 파트 컨텐츠 헤더 헤드 헤드 데스크 소개-컨텐츠-베이스 URL의 헤더에 사용됩니다. 바디의 URL the 컨텐츠에 대한 대의적 인코딩 방법에 대해 대상 컨텐츠-언어에 대해 수행 된 가장 적절한 자연 언어는 대상 컨텐츠 길이를 이해할 때 사용하기에 가장 적합한 자연 언어입니다. 제목의 길이 또는 크기Content -Location

	Set-Cookie2
WWW-Authenticate	서버에서 클라이언트의 챌린지 목록까지

리소스 엔터티가 위치한 위치

Content-MD5

본문의 MD5 체크섬

Content-Range리소스 범위 전체 리소스에서 이 엔터티로 표시됩니다Content- Type이 주제의 객체 유형엔티티 캐시 헤더HeaderDescriptionETag 이 엔터티와 연결된 엔터티 태그Expires엔터티가 존재하지 않습니다. 원본 소스에서 이 엔터티의 날짜와 시간을 다시 가져오려면 유효합니다. Last-Modified이 엔터티가 있었던 날짜와 시간 최종 수정됨상태 코드는 클라이언트입니다. 거래 결과를 빠르게 이해할 수 있는 방법을 제공합니다. : 정보용 상태 코드








상태

상태 코드 지침 클라이언트 요청의 초기 부분이 수신되었습니다. 계속하세요. 이 상태 코드를 보낸 후 서버는 요청을 받은 후 응답해야 합니다Switching Protocols

200-299: 성공 상태 코드

클라이언트가 요청을 보낼 때 이러한 요청은 일반적으로 성공합니다. 200

Rea 아들 문구	의미
100	Continue
	101
서버가 클라이언트 사양에 따라 업데이트 헤더에 나열된 프로토콜로 프로토콜을 전환하고 있음을 나타냅니다

알았어 요청에는 문제가 없습니다. 201Created의 엔터티 부분은 서버에서 개체 요청을 생성하는 데 사용됩니다. 응답에는 생성을 위한 다양한 참조가 포함되어야 합니다. 리소스의 URL, Location 헤더에는 가장 구체적인 참조가 포함되어 있으며, 서버는 이 상태를 보내기 전에 객체를 생성해야 합니다. 202Accepted요청이 수락되었지만 서버는 이에 대해 어떤 작업도 수행하지 않았습니다. 서버가 요청을 완료한다는 보장은 없으며, 이는 요청이 수락되면 유효한 것으로 보인다는 의미일 뿐입니다. 서버는 엔터티 본문에 요청 상태에 대한 설명을 포함해야 하며 요청이 완료되는 예상 시간(또는 이 정보를 얻을 수 있는 위치에 대한 포인터 포함)을 포함해야 합니다. 203Non -신뢰할 수 있는 정보 엔터티 헤더에 포함된 정보는 원본 서버에서 가져온 것이 아니라 리소스 복사본에서 가져온 것입니다. 이러한 상황은 중간 노드에 리소스 복사본이 있지만 해당 노드에서 보낸 리소스와 관련된 메타 정보(헤더)가 204No Content에서 확인할 수 없는 경우에 발생합니다. 응답 메시지에는 여러 헤더와 상태 줄이 포함되어 있지만 엔터티 본문은 없습니다. 새 문서로 변환하지 않고 브라우저를 업데이트하는 데 주로 사용됩니다(예: 표현식 페이지 새로 고침)205Reset Content브라우저에 주로 사용되는 또 다른 코드입니다. 현재 페이지의 모든 html 태그를 지우도록 브라우저에 지시하는 역할을 담당합니다206Partail Content부분 또는 범위 요청을 성공적으로 실행합니다. 나중에 클라이언트가 일부 특수 헤더를 통해 문서의 일부 또는 범위를 얻을 수 있음을 확인할 수 있습니다. ——이 상태 코드는 범위 요청이 성공했음을 나타냅니다응답에는 Content-Range, Date 및 ETag 또는 Content-Location Header가 포함되어야 합니다.

300-399: 리디렉션 상태 코드

리디렉션 상태 코드는 클라이언트에게 관심 있는 리소스에 액세스하기 위해 대체 위치를 사용하거나 리소스의 콘텐츠 대신 대체 응답을 제공하도록 지시합니다. 리소스가 이동된 경우 리디렉션 상태 코드와 선택적 위치 헤더를 전송하여 클라이언트에게 리소스가 이동되었으며 현재 찾을 수 있는 위치를 알릴 수 있습니다

305프록시 사용은 리소스가 프록시를 통해 액세스되어야 함을 나타내는 데 사용됩니다. 에이전트의 위치는 위치로 제공됩니다. 클라이언트는 특정 리소스와 관련하여 이 응답을 구문 분석하며 모든 요청 또는 요청을 보유한 서버에 대한 모든 요청이 이 프록시를 통해 이루어진다고 가정할 수 없다는 점에 유의하는 것이 중요합니다. 클라이언트가 실수로 프록시의 요청 개입을 허용하면 파괴적인 동작이 발생하고 보안 유출 문제가 발생할 수 있습니다306UnusedUnused307Temporary Redirectwith Temporary Redirect 301 상태 코드는 유사하지만 클라이언트는 위치 헤더에 제공된 URL을 사용하여 일시적으로 리소스를 찾아야 합니다. 향후 리소스는 이전 URL을 사용해야 합니다

400-499: 클라이언트 오류 상태 코드

때때로 클라이언트는 잘못된 형식의 요청 메시지나 가장 일반적으로 존재하지 않는 URL

상태 코드	이유 문구	의미
300	Multiple Choices	이 상태 코드는 클라이언트 요청이 실제로 여러 리소스를 가리키는 URL인 경우 반환됩니다. 예를 들어 서버의 HTML 문서에 중국어와 영어 버전이 있습니다. 이 코드는 옵션 열과 함께 반환됩니다. 이렇게 하면 요청 URL이 이동되었을 때 사용자가 사용하려는 코드를
301	Moved Permanently	선택할 수 있습니다. 응답의 Loaction 헤더에는 리소스가 있는 URL이 포함되어 있습니다.
302	Found	은 301과 유사하지만 클라이언트는 임시 위치 리소스를 얻으려면 Location 헤더에 제공된 URL을 사용해야 합니다. 향후 요청은 이전 리소스를 사용할 수 있습니다.
303	Set Ohter	는 클라이언트에게 리소스를 얻으려면 다른 URL을 사용해야 한다고 알려줍니다. 새 URL 리소스는 응답 메시지의 Location 헤더에 있습니다. 주요 목적은 POST 요청의 응답이 클라이언트를 특정 리소스
304	Not Modified	로 안내하도록 허용하는 것입니다. 클라이언트는 포함된 요청 헤더를 통해 요청을 조건부로 만들 수 있습니다. 클라이언트가 GET 요청을 보내고 리소스가 최근에 변경되지 않은 경우 이 상태 코드를 사용하여 리소스가 수정되지 않았음을 나타낼 수 있습니다. 이 상태 코드가 있는 응답에는 엔터티 부분이 포함되어서는 안 됩니다.

등 서버가 처리할 수 없는 것을 보내는 경우가 있습니다. 410Gone은 서버가 이 리소스를 소유했다는 점을 제외하면 404와 유사합니다. 리소스가 제거될 때 서버 관리자가 클라이언트에 알릴 수 있도록 주로 웹 사이트 유지 관리에 사용됩니다. 클라이언트가 요청 조건을 보내고 조건 중 하나가 실패할 때 사용됩니다. 클라이언트가 Expect 헤더를 포함하면 조건부 요청을 보냅니다클라이언트가 보낸 엔터티 본문 부분이 서버에서 처리할 수 있거나 처리하려는 것보다 크면 이 상태 코드를 사용하세요이 상태 코드는 클라이언트가 서버에서 처리할 수 있거나 처리하려는 것보다 긴 요청 URL이 포함된 요청을 보낼 때 사용됩니다. 서버는 클라이언트가 엔터티의 콘텐츠 유형을 보내는 것을 이해하거나 지원할 수 없습니다. 이 상태 코드를 사용하세요 요청 메시지는 특정 범위의 리소스를 요청하는 것이며 이 범위는 유효하지 않거나 만족할 수 없는 경우 이 상태 코드를 사용하세요 요청된 Expect 요청에 기대치가 포함되어 있지만 이 상태 코드는 서버가 이 기대치를 충족할 수 없을 때 사용됩니다. 프록시 또는 기타 중개 프로그램에 원본 서버가 요청에 대한 실패 예상을 생성한다는 확실한 증거가 있는 경우 이 상태 코드를 보낼 수 있습니다

상태 코드 이유 문구 의미

400 Bad Request 는 클라이언트에게 잘못된 요청이 전송되었음을 알리는 데 사용됩니다

401 Unauthorized 적절한 헤더 사용 , 이 헤더에는 리소스에 액세스하기 전에 클라이언트에게 인증을 요청합니다.

402 결제 필요 상태 코드는 사용되지 않습니다

403 Forbidden 은 서버에서 거부된 요청을 설명하는 데 사용됩니다. 서버가 요청을 거부하는 이유를 설명하는 경우 이를 설명하는 엔터티의 본문 부분을 포함할 수 있습니다. 하지만 이 상태 코드는 일반적으로 서버가 이유를 설명하고 싶지 않을 때 사용됩니다.

404 Not Found 는 서버가 요청한 URL을 찾을 수 없음을 설명하는 데 사용됩니다. 일반적으로 클라이언트 애플리케이션이 사용자에게

405 Method Not Allowed 를 표시할 수 있도록 엔터티가 포함됩니다. 이 상태 코드는 요청된 URL에서 지원되지 않는 메서드로 요청이 전송될 때 사용됩니다. 요청된 리소스에 어떤 메서드를 사용할 수 있는지 클라이언트에게 알리기 위해 응답에 Allow 헤더가 포함되어야 합니다.

406 허용되지 않음 클라이언트는 허용할 엔터티 유형을 나타내는 매개 변수를 지정할 수 있습니다. 이 코드는 클라이언트가 수락한 URL과 일치하는 리소스가 서버에 없을 때 사용됩니다. 일반적으로 서버에는 클라이언트가 요청을 충족할 수 없는 이유를 파악할 수 있도록 일부 헤더가 포함됩니다.

407 프록시 인증 필요 401과 유사하지만 리소스 인증이 필요한 프록시 서버에 사용됩니다.

408 요청 시간 초과 클라이언트의 요청이 너무 오래 걸리는 경우 서버는 이 상태 코드를 반환하고 연결을 닫을 수 있습니다. 시간 초과는 서버마다 다르지만 일반적으로 모든 합법적인 서버에 대해 충분히 길다.

409 Con conflict 는 요청으로 인해 리소스에 충돌이 발생했을 수 있음을 나타내는 데 사용됩니다. 서버는 충돌이 우려되는 경우 이 상태 코드를 보낼 수 있습니다. 응답에는 충돌을 설명하는 본문이 포함되어야 합니다.

412 Precondition Falied

413 Request Entiny Too Large

414 요청 URL이 너무 깁니다

415 지원되지 않는 미디어 유형

416 요청 범위가 만족스럽지 않음

417 Expection Failed

500-599: 서버 오류 상태 코드

때때로 클라이언트가 요청을 보냈는데 서버 자체에 오류가 발생하는 경우

상태 코드	이유 문구	의미
500	내부 서버 오류	이 상태 코드는 서버에서 요청 처리를 방해하는 오류가 발생했을 때 사용됩니다.
501	Not Inplemented	이 상태는 클라이언트가 서버 외부로 요청을 보낼 때 사용됩니다. 기능 코드
502	Bad Gateway	프록시 또는 게이트웨이로 사용됨 이 상태 코드는 서버가 응답 체인의 다음 링크에서 가짜 응답을 수신할 때 사용됩니다
503	Service Unavailable	서버가 지금은 요청을 처리할 수 없지만 나중에는 처리할 수 있음을 나타내는 데 사용됩니다. 서버가 리소스를 사용할 수 있는 시기를 알고 있는 경우 응답에 Retry-after 헤더를 포함할 수 있습니다.
504	Gateway Timeout	은 여기서 응답이 게이트웨이 또는 서버가 요청에 응답하는 동안 시간이 초과되었습니다.
505	HTTP 버전이 지원되지 않습니다	서버가 지원할 수 없거나 지원할 의사가 없는 프로토콜 버전을 사용하여 요청을 받았습니다. 이 상태를 사용하세요. 암호. 일부 서버 애플리케이션은 프로토콜의 초기 버전을 지원하지 않기로 선택합니다

github에서 이 페이지를 편집하세요
Blogger의 개인 블로그
참조: http 프로토콜
[http 권위 있는 가이드]