이 기사에서는 http 프로토콜의 프런트 엔드에 대한 몇 가지 상식 문제를 공유합니다. 관심 있는 친구는
http
소개를 살펴보세요. http는 tcp/를 기반으로 데이터를 전송합니다. ip 통신
Notes
http는 연결이 없습니다. 각 연결은 하나의 요청만 처리합니다. 서버가 요청을 처리하고 클라이언트로부터 응답을 받은 후
http 미디어는 독립적입니다. 클라이언트와 서버는 데이터 유형을 처리하는 방법을 알고 있으며 모든 데이터는 http를 사용하여 전송될 수 있습니다.
http 무상태: 프로토콜에 트랜잭션 처리를 위한 메모리 기능이 없음을 의미합니다. 클라이언트 요청에는 요청 라인, 요청 헤더, 빈 라인 및 요청 데이터
2. http 응답: 상태 라인, 메시지 헤더, 빈 라인, 응답 본문
http 요청 방법
http1.0 : get, post 및 head
http1.1에는 5개의 새로운 요청 메소드 추가: delete, put, connect, tarce 및 options-
method
description
|
get |
Initiate a 특정 리소스에 요청
| 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 |
어떤 확장 전송 인코딩을 사용할 수 있는지 서버에 알려줍니다. |
조건부 요청 헤더
| Header |
Description |
| Allow client columns 요청에 필요한 서버 동작 |
|
If-Match
| 엔터티 태그가 문서의 현재 엔터티 태그와 일치하는 경우 , 문서 가져오기 |
|
If-Modify-Since
| 지정된 날짜 이후에 리소스가 수정되지 않은 경우, 그렇지 않으면 이 요청을 제한하세요. |
|
If-None-Match
| 엔터티 태그가 일치하지 않는 경우 문서의 현재 엔터티, 문서 가져오기 |
|
If-Range
| 문서 변경 허용 범위 조건부 요청 |
|
If-Unmodified-Since
| 리소스가 특정 날짜 이후에 수정되지 않은 경우 제외 그렇지 않으면 이 요청을 제한하세요 |
|
Range
| 서버가 범위 요청을 지원하는 경우 리소스의 지정된 범위 |
|
보안 요청은 헤더
에 의해 제어됩니다. 헤더
| describes | |
Authorization
| 에는 클라이언트가 자신을 인증하기 위해 서버에 제공한 데이터가 포함되어 있습니다. |
| Cookie
| 클라이언트는 이를 사용하여 서버에 토큰을 보냅니다. 이는 실제 보안 헤더가 아닙니다. 보안 기능을 암시합니다 |
|
Cookie2
| 는 요청자가 지원하는 쿠키 버전을 나타내는 데 사용됩니다 |
|
프록시 요청 헤더
Header
| Description |
|
Max-Forward
| 요청이 서버 경로의 다른 프록시 또는 게이트웨이로 전달되는 최대 횟수———— TARCE 방법과 함께 사용됩니다. |
|
Proxy-Authorization
| Authorization 헤더와 동일하지만 이 헤더는 프록시로 인증할 때 사용됩니다. |
|
Proxy-Connection
| Connection 헤더와 동일하지만 이 헤더는 프록시로 인증할 때 사용됩니다. |
|
프록시와 연결을 설정할 때 사용됩니다.응답 헤더
응답 메시지에는 클라이언트에 정보를 제공하기 위한 자체 헤더 세트가 있습니다. (처음부터 생성 시작) 응답 기간
Publick
서버에서 해당 리소스에 대해 지원하는 요청 방법 목록
|
Retry-After |
리소스를 사용할 수 없는 경우 이 날짜 또는 시간에 다시 시도
| Server |
서버 응용 프로그램의 이름과 버전 |
| Title |
HTML 문서의 경우 HTML 문서의 소스에서 부여한 제목입니다 |
| Wraning |
이유문 텍스트보다 더 자세한 경고 보고서 |
| 협상 헤더 |
| Header |
Description |
|
Accept-Ranges |
이 리소스에 대해 서버에서 허용하는 데이터 유형
다양함
서버 보기 기타 헤더 목록은 다음과 같습니다. 응답을 변경합니다. 즉, 이것은 헤더 목록이며 서버는 이러한 헤더의 내용을 기반으로 가장 적절한 리소스 버전을 선택하여 클라이언트에 보냅니다
|
| 보안 응답 헤더
| Header |
Description |
|
Proxy-Authenticate |
프록시에서 클라이언트로의 쿼리 목록
Set-Cookie
은 실제 보안 헤더는 아니지만 보안 기능을 의미합니다. 서버를 통해 클라이언트에 서명하려면 클라이언트 보안 토큰에 설정하세요
|
Set-Cookie2 |
Set-Cookie와 유사
| WWW-Authenticate |
서버에서 클라이언트의 챌린지 목록까지 |
| 엔티티 헤더 |
엔티티 헤더는 엔티티 바디 파트 컨텐츠 헤더
|
| 헤드 헤드 데스크 소개-컨텐츠-베이스 URL의 헤더에 사용됩니다. 바디의 URL the
| | 컨텐츠에 대한 대의적 인코딩 방법에 대해 대상 컨텐츠-언어에 대해 수행 된 가장 적절한 자연 언어는 대상 컨텐츠 길이를 이해할 때 사용하기에 가장 적합한 자연 언어입니다. 제목의 길이 또는 크기 |
Content -Location
리소스 엔터티가 위치한 위치
Content-MD5
본문의 MD5 체크섬
Content-Range | 리소스 범위 전체 리소스에서 이 엔터티로 표시됩니다 |
Content- Type
이 주제의 객체 유형 |
|
엔티티 캐시 헤더
|
| Header
Description |
|
ETag | 이 엔터티와 연결된 엔터티 태그 |
Expires | 엔터티가 존재하지 않습니다. 원본 소스에서 이 엔터티의 날짜와 시간을 다시 가져오려면 유효합니다. |
Last-Modified | 이 엔터티가 있었던 날짜와 시간 최종 수정됨 |
| 상태 |
| 상태 코드는 클라이언트입니다. 거래 결과를 빠르게 이해할 수 있는 방법을 제공합니다.
|
| : 정보용 상태 코드
상태 코드
| Rea 아들 문구 |
의미 |
| 100 | Continue |
지침 클라이언트 요청의 초기 부분이 수신되었습니다. 계속하세요. 이 상태 코드를 보낸 후 서버는 요청을 받은 후 응답해야 합니다
|
101 |
Switching Protocols
| 서버가 클라이언트 사양에 따라 업데이트 헤더에 나열된 프로토콜로 프로토콜을 전환하고 있음을 나타냅니다 |
|
클라이언트가 요청을 보낼 때 이러한 요청은 일반적으로 성공합니다. 200
알았어 요청에는 문제가 없습니다. |
| 201 | Created 의 엔터티 부분은 서버에서 개체 요청을 생성하는 데 사용됩니다. 응답에는 생성을 위한 다양한 참조가 포함되어야 합니다. 리소스의 URL, Location 헤더에는 가장 구체적인 참조가 포함되어 있으며, 서버는 이 상태를 보내기 전에 객체를 생성해야 합니다.
| 202 | Accepted | 요청이 수락되었지만 서버는 이에 대해 어떤 작업도 수행하지 않았습니다. 서버가 요청을 완료한다는 보장은 없으며, 이는 요청이 수락되면 유효한 것으로 보인다는 의미일 뿐입니다. 서버는 엔터티 본문에 요청 상태에 대한 설명을 포함해야 하며 요청이 완료되는 예상 시간(또는 이 정보를 얻을 수 있는 위치에 대한 포인터 포함)을 포함해야 합니다.
| 203 | Non -신뢰할 수 있는 정보 | 엔터티 헤더에 포함된 정보는 원본 서버에서 가져온 것이 아니라 리소스 복사본에서 가져온 것입니다. 이러한 상황은 중간 노드에 리소스 복사본이 있지만 해당 노드에서 보낸 리소스와 관련된 메타 정보(헤더)가
| 204 | No Content | 에서 확인할 수 없는 경우에 발생합니다. 응답 메시지에는 여러 헤더와 상태 줄이 포함되어 있지만 엔터티 본문은 없습니다. 새 문서로 변환하지 않고 브라우저를 업데이트하는 데 주로 사용됩니다(예: 표현식 페이지 새로 고침)
| 205 | Reset Content | 브라우저에 주로 사용되는 또 다른 코드입니다. 현재 페이지의 모든 html 태그를 지우도록 브라우저에 지시하는 역할을 담당합니다
| 206 | Partail Content | 부분 또는 범위 요청을 성공적으로 실행합니다. 나중에 클라이언트가 일부 특수 헤더를 통해 문서의 일부 또는 범위를 얻을 수 있음을 확인할 수 있습니다. ——이 상태 코드는 범위 요청이 성공했음을 나타냅니다 응답에는 Content-Range, Date 및 ETag 또는 Content-Location Header
| 가 포함되어야 합니다. |
|
|
|
리디렉션 상태 코드는 클라이언트에게 관심 있는 리소스에 액세스하기 위해 대체 위치를 사용하거나 리소스의 콘텐츠 대신 대체 응답을 제공하도록 지시합니다. 리소스가 이동된 경우 리디렉션 상태 코드와 선택적 위치 헤더를 전송하여 클라이언트에게 리소스가 이동되었으며 현재 찾을 수 있는 위치를 알릴 수 있습니다
| 상태 코드 |
이유 문구 | 의미 |
| 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 요청을 보내고 리소스가 최근에 변경되지 않은 경우 이 상태 코드를 사용하여 리소스가 수정되지 않았음을 나타낼 수 있습니다. 이 상태 코드가 있는 응답에는 엔터티 부분이 포함되어서는 안 됩니다. | 305
프록시 사용 | 은 리소스가 프록시를 통해 액세스되어야 함을 나타내는 데 사용됩니다. 에이전트의 위치는 위치로 제공됩니다. 클라이언트는 특정 리소스와 관련하여 이 응답을 구문 분석하며 모든 요청 또는 요청을 보유한 서버에 대한 모든 요청이 이 프록시를 통해 이루어진다고 가정할 수 없다는 점에 유의하는 것이 중요합니다. 클라이언트가 실수로 프록시의 요청 개입을 허용하면 파괴적인 동작이 발생하고 보안 유출 문제가 발생할 수 있습니다 |
| 306
Unused | Unused |
| 307
Temporary Redirect | with Temporary Redirect | 301 상태 코드는 유사하지만 클라이언트는 위치 헤더에 제공된 URL을 사용하여 일시적으로 리소스를 찾아야 합니다. 향후 리소스는 이전 URL을 사용해야 합니다 |
때때로 클라이언트는 잘못된 형식의 요청 메시지나 가장 일반적으로 존재하지 않는 URL
| 상태 코드 | 등 서버가 처리할 수 없는 것을 보내는 경우가 있습니다. 이유 문구 |
의미 |
| 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 |
는 요청으로 인해 리소스에 충돌이 발생했을 수 있음을 나타내는 데 사용됩니다. 서버는 충돌이 우려되는 경우 이 상태 코드를 보낼 수 있습니다. 응답에는 충돌을 설명하는 본문이 포함되어야 합니다. | 410
Gone | 은 서버가 이 리소스를 소유했다는 점을 제외하면 404와 유사합니다. 리소스가 제거될 때 서버 관리자가 클라이언트에 알릴 수 있도록 주로 웹 사이트 유지 관리에 사용됩니다. 412 |
Precondition Falied |
클라이언트가 요청 조건을 보내고 조건 중 하나가 실패할 때 사용됩니다. 클라이언트가 Expect 헤더를 포함하면 조건부 요청을 보냅니다
|
413 |
Request Entiny Too Large |
클라이언트가 보낸 엔터티 본문 부분이 서버에서 처리할 수 있거나 처리하려는 것보다 크면 이 상태 코드를 사용하세요 | 414 |
요청 URL이 너무 깁니다 |
이 상태 코드는 클라이언트가 서버에서 처리할 수 있거나 처리하려는 것보다 긴 요청 URL이 포함된 요청을 보낼 때 사용됩니다.
|
415 |
지원되지 않는 미디어 유형 |
서버는 클라이언트가 엔터티의 콘텐츠 유형을 보내는 것을 이해하거나 지원할 수 없습니다. 이 상태 코드를 사용하세요
|
416 |
요청 범위가 만족스럽지 않음 |
요청 메시지는 특정 범위의 리소스를 요청하는 것이며 이 범위는 유효하지 않거나 만족할 수 없는 경우 이 상태 코드를 사용하세요
|
417 |
Expection Failed |
요청된 Expect 요청에 기대치가 포함되어 있지만 이 상태 코드는 서버가 이 기대치를 충족할 수 없을 때 사용됩니다. 프록시 또는 기타 중개 프로그램에 원본 서버가 요청에 대한 실패 예상을 생성한다는 확실한 증거가 있는 경우 이 상태 코드를 보낼 수 있습니다
|
때때로 클라이언트가 요청을 보냈는데 서버 자체에 오류가 발생하는 경우
| 상태 코드 |
이유 문구 |
의미 |
| 500 |
내부 서버 오류 |
이 상태 코드는 서버에서 요청 처리를 방해하는 오류가 발생했을 때 사용됩니다. |
| 501 |
Not Inplemented |
이 상태는 클라이언트가 서버 외부로 요청을 보낼 때 사용됩니다. 기능 코드 |
| 502 |
Bad Gateway |
프록시 또는 게이트웨이로 사용됨 이 상태 코드는 서버가 응답 체인의 다음 링크에서 가짜 응답을 수신할 때 사용됩니다 |
| 503 |
Service Unavailable |
서버가 지금은 요청을 처리할 수 없지만 나중에는 처리할 수 있음을 나타내는 데 사용됩니다. 서버가 리소스를 사용할 수 있는 시기를 알고 있는 경우 응답에 Retry-after 헤더를 포함할 수 있습니다. |
| 504 |
Gateway Timeout |
은 여기서 응답이 게이트웨이 또는 서버가 요청에 응답하는 동안 시간이 초과되었습니다. |
| 505 |
HTTP 버전이 지원되지 않습니다 |
서버가 지원할 수 없거나 지원할 의사가 없는 프로토콜 버전을 사용하여 요청을 받았습니다. 이 상태를 사용하세요. 암호. 일부 서버 애플리케이션은 프로토콜의 초기 버전을 지원하지 않기로 선택합니다 |
github에서 이 페이지를 편집하세요
Blogger의 개인 블로그
참조: http 프로토콜
[http 권위 있는 가이드]
관련 권장 사항:
http 프로토콜을 사용하는 과정
HTTP 프로토콜이란 무엇입니까
Http 프로토콜과 TCP 프로토콜의 차이점은 무엇입니까
|
|
|
위 내용은 HTTP 프로토콜 프런트엔드 상식의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!
