[컴퓨터 네트워크]: http 메시지 상세 설명
HTTP 요청 메시지
HTTP 요청 메 시 지 는 요청 줄 (request line), 요청 헤더 (header), 빈 줄, 요청 데이터 4 개 부분 으로 구성 되 어 있 으 며, 아래 그림 은 요청 메시지 의 일반적인 형식 을 보 여 줍 니 다.
or
<request-line> <headers> <blank line> [<request-body>
1. 요청 헤더
요청 줄 은 요청 방법 필드, URL 필드, HTTP 프로 토 콜 버 전 필드 3 개 필드 로 구성 되 어 있 으 며 빈 칸 으로 구 분 됩 니 다. 예 를 들 어 GET / index. html HTTP / 1.1.
HTTP 프로 토 콜 의 요청 방법 은 GET, POST, HEAD, PUT, DELETE, OPTIONS, TRACE, CONNECT 가 있 습 니 다.
흔히 볼 수 있 는 것 은 다음 과 같은 몇 가지 가 있다.
1).GET
클 라 이언 트 가 서버 에서 문 서 를 읽 으 려 면 웹 페이지 의 링크 를 클릭 하거나 브 라 우 저의 주소 표시 줄 에 웹 주 소 를 입력 하여 웹 페이지 를 탐색 할 때 GET 방식 을 사용 합 니 다. GET 방법 은 서버 에 URL 위치 에 있 는 자원 을 응답 메시지 의 데이터 부분 에 두 고 클 라 이언 트 에 게 보 내 도록 합 니 다. GET 방법 을 사용 할 때 요청 파라미터 와 대응 하 는 요청 파 라미 터 를 사용 합 니 다.의 값 을 URL 뒤에 추가 하고 물음표 ("?") 를 사용 합 니 다.URL 의 끝 과 요청 매개 변 수 를 나타 내 는 시작 으로 전달 매개 변수 길이 가 제 한 됩 니 다. 예 를 들 어 / index. jsp? id = 100 & op = bid 는 GET 방식 으로 전 달 된 데 이 터 를 주소 에 직접 표시 하기 때문에 요청 결 과 를 친구 에 게 링크 로 보 낼 수 있 습 니 다. google 검색 domety 의 경우 Request 형식 은 다음 과 같 습 니 다.
GET /search?hl=zh-CN&source=hp&q=domety&aq=f&oq= HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-excel, application/vnd.ms-powerpoint,
application/msword, application/x-silverlight, application/x-shockwave-flash, */*
Referer: <a href="http://www.google.cn/">http://www.google.cn/</a>
Accept-Language: zh-cn
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727; TheWorld)
Host: <a href="http://www.google.cn">www.google.cn</a>
Connection: Keep-Alive
Cookie: PREF=ID=80a06da87be9ae3c:U=f7167333e2c3b714:NW=1:TM=1261551909:LM=1261551917:S=ybYcq2wpfefs4V9g;
NID=31=ojj8d-IygaEtSxLgaJmqSjVhCspkviJrB6omjamNrSm8lZhKy_yMfO2M4QMRKcH1g0iQv9u-2hfBW7bUFwVh7pGaRUb0RnHcJU37y-
FxlRugatx63JLv7CWMD6UB_O_r
GET 방식 의 요청 은 일반적으로 '요청 내용' 부분 을 포함 하지 않 습 니 다. 요청 데 이 터 는 요청 줄 에 주소 로 표 시 됩 니 다. 주소 링크 는 다음 과 같 습 니 다.
<a href="http://www.google.cn/search?hl=zh-CN&source=hp&q=domety&aq=f&oq=">http://www.google.cn/search?hl=zh-CN&source=hp
&q=domety&aq=f&oq=</a>
"주소 중"? "다음 부분 은 GET 를 통 해 보 내 는 요청 데이터 입 니 다. 주소 표시 줄 에서 각 데 이 터 를" & "기호 로 구분 할 수 있 습 니 다. 이러한 방식 은 비밀 데 이 터 를 전송 하 는 데 적합 하지 않 습 니 다. 또한 브 라 우 저 마다 주소 에 대한 문자 제한 이 다 르 기 때문에 보통 1024 글자 만 식별 할 수 있 습 니 다. 따라서 전송 이 필요 하 다 면대량의 데 이 터 를 사용 할 때 도 GET 방식 을 사용 하기에 적합 하지 않다.
2).POST
위 에서 언급 한 GET 방식 이 적합 하지 않 은 경우 POST 방식 을 고려 할 수 있 습 니 다. POST 방법 을 사용 하면 클 라 이언 트 가 서버 에 정 보 를 많이 제공 할 수 있 기 때 문 입 니 다. POST 방법 은 요청 파 라미 터 를 HTTP 요청 데이터 에 봉 하여 이름 / 값 으로 나타 나 고 대량의 데 이 터 를 전송 할 수 있 습 니 다. 이렇게 POST 방식 은 전송 하 는 데이터 크기 에 제한 이 없 으 며 전송 하 는 데이터 크기 에 도 제한 이 없습니다.URL 에 표 시 됩 니 다. 또한 위 에서 domety 를 검색 할 때 POST 방식 을 사용 하면 다음 과 같은 형식 을 사용 합 니 다.
POST /search HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-excel, application/vnd.ms-powerpoint,
application/msword, application/x-silverlight, application/x-shockwave-flash, */*
Referer: <a href="http://www.google.cn/">http://www.google.cn/</a>
Accept-Language: zh-cn
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727; TheWorld)
Host: <a href="http://www.google.cn">www.google.cn</a>
Connection: Keep-Alive
Cookie: PREF=ID=80a06da87be9ae3c:U=f7167333e2c3b714:NW=1:TM=1261551909:LM=1261551917:S=ybYcq2wpfefs4V9g;
NID=31=ojj8d-IygaEtSxLgaJmqSjVhCspkviJrB6omjamNrSm8lZhKy_yMfO2M4QMRKcH1g0iQv9u-2hfBW7bUFwVh7pGaRUb0RnHcJU37y-
FxlRugatx63JLv7CWMD6UB_O_r
hl=zh-CN&source=hp&q=domety
POST 방식 요청 줄 에는 데이터 문자열 이 포함 되 어 있 지 않 습 니 다. 이 데 이 터 는 '요청 내용' 부분 에 저 장 됩 니 다. 각 데이터 간 에 도 '&' 기 호 를 사용 합 니 다. POST 방식 은 대부분 페이지 의 폼 에 사 용 됩 니 다. POST 도 GET 기능 을 수행 할 수 있 기 때문에 대부분의 사람들 이 폼 을 디자인 할 때 POST 방식 을 사용 합 니 다. 사실은 잘못된 부분 입 니 다. GET 방식 도 마찬가지 입 니 다.자신의 특징 과 장점 이 있 기 때문에 우 리 는 상황 에 따라 GET 를 사용 할 지 POST 를 사용 할 지 선택해 야 한다.
3).HEAD
HEAD 는 GET 와 같 습 니 다. 서버 에서 HEAD 요청 을 받 은 후 응답 헤더 만 되 돌려 주 고 응답 내용 을 보 내지 않 습 니 다. 한 페이지 의 상태 만 볼 때 HEAD 를 사용 하 는 것 은 매우 효율 적 입 니 다. 전송 과정 에서 페이지 내용 을 줄 이기 때 문 입 니 다.
2. 머리 요청
요청 머리 는 키워드 / 값 쌍 으로 구성 되 어 있 습 니 다. 줄 마다 한 쌍 씩, 키워드 와 값 은 영문 콜론 으로 구 분 됩 니 다. 요청 머리 는 서버 에 클 라 이언 트 요청 에 대한 정보 가 있 습 니 다. 전형 적 인 요청 머리 는 다음 과 같 습 니 다.
User - agent: 요청 한 브 라 우 저 형식 입 니 다.
Accept: 클 라 이언 트 가 식별 할 수 있 는 내용 유형 목록 입 니 다.
Host: 요청 한 호스트 이름 입 니 다. 여러 도 메 인 이름 이 같은 IP 주소, 즉 가상 호스트 를 사용 할 수 있 습 니 다.
3. 공 행
마지막 요청 헤더 다음 에 빈 줄 입 니 다. 리 턴 문자 와 줄 바 꿈 부 호 를 보 내 고 서버 아래 에 요청 헤더 가 없 음 을 알 립 니 다.
4. 요청 데이터
요청 데 이 터 는 GET 방법 이 아 닌 POST 방법 에서 사 용 됩 니 다. POST 방법 은 고객 이 양식 을 작성 해 야 하 는 경우 에 적 용 됩 니 다. 요청 데이터 와 관련 된 가장 많이 사용 되 는 요청 헤 더 는 Content - Type 과 Content - Length 입 니 다.
HTTP 메시지
HTTP 응답 도 세 부분 으로 구성 되 는데 그것 이 바로 상태 줄, 메시지 헤더, 응답 본문 이다.
다음 과 같이 HTTP 응답의 형식 과 요청 의 형식 은 매우 유사 하 다. < status - line > < headers > < blank line > [< response - body >]
보다 시 피 응답 에서 유일한 차이 점 은 첫 번 째 줄 에서 요청 정 보 를 상태 정보 로 대체 하 는 것 입 니 다. 상태 줄 (status line) 은 상태 코드 를 제공 하여 요청 한 자원 상황 을 설명 합 니 다.
상태 줄 형식 은 다음 과 같 습 니 다:
HTTP-Version Status-Code Reason-Phrase CRLF
그 중에서 HTTP - Version 은 서버 HTTP 프로 토 콜 의 버 전 을 나타 내 고, Status - code 는 서버 가 보 낸 응답 상태 코드 를 나타 내 며, Reason - Presase 는 상태 코드 를 나타 내 는 텍스트 설명 을 나타 낸다. 상태 코드 는 세 자리 숫자 로 구성 되 어 있 으 며, 첫 번 째 숫자 는 응답 유형 을 정의 하고, 다섯 가지 값 을 가 져 올 수 있다.
1xx: 지시 정보 -- 요청 이 접수 되 었 음 을 표시 하고 계속 처리 합 니 다. 2xx: 성공 - 요청 이 성공 적 으로 받 아들 여지 고 이해 되 며 받 아들 여 졌 음 을 나타 낸다. 3xx: 방향 을 바 꾸 기 -- 요청 을 완성 하려 면 더 많은 작업 을 해 야 합 니 다. 4xx: 클 라 이언 트 오류 -- 요청 에 문법 오류 가 있 거나 요청 이 실 현 될 수 없습니다. 5xx: 서버 쪽 오류 -- 서버 가 합 법 적 인 요청 을 수행 하지 못 했 습 니 다. 일반적인 상태 코드, 상태 설명 은 다음 과 같다.
200 OK: 클 라 이언 트 요청 성공. 400 Bad Request: 클 라 이언 트 요청 에 문법 오류 가 있어 서버 에서 이해 할 수 없습니다. 401 Unauthorized: 권한 이 부여 되 지 않 은 요청 입 니 다. 이 상태 코드 는 WWW - Authenticate 헤더 필드 와 함께 사용 해 야 합 니 다. 403 Forbidden: 서버 에서 요청 을 받 았 으 나 서비스 제공 을 거부 합 니 다. 404 Not Found: 요청 자원 이 존재 하지 않 습 니 다. 예 를 들 어 잘못된 URL 을 입력 하 였 습 니 다. 500 내부 서버 오류: 서버 에 예상 치 못 한 오류 가 발생 했 습 니 다. 503 Server Unavailable: 서버 는 현재 클 라 이언 트 의 요청 을 처리 할 수 없습니다. 일정 시간 후에 정상 으로 돌아 올 수 있 습 니 다. 예 를 들 어 HTTP / 1.1 200 OK (CRLF).
다음은 HTTP 응답 메시지 의 예 를 보 여 줍 니 다.
HTTP/1.1 200 OK
Date: Sat, 31 Dec 2005 23:59:59 GMT
Content-Type: text/html;charset=ISO-8859-1
Content-Length: 122
<html>
<head>
<title>Wrox Homepage</title>
</head>
<body>
<!-- body goes here -->
</body>
</html>
HTTP 요청 GET 와 POST 의 차이 점
1. GET 제출, 요청 한 데 이 터 는 URL 뒤에 첨부 됩 니 다 (HTTP 프로 토 콜 헤더 < request - line > 에 데 이 터 를 배치 하 는 것 입 니 다)URL 을 분할 하고 데 이 터 를 전송 합 니 다. 여러 매개 변 수 를 & 로 연결 합 니 다. 예 를 들 어 login. action? name = hydd & password = idontknow & verify =% E4% BD% A0% E5% A5% BD 입 니 다. 데이터 가 영문 자모 / 숫자 라면 그대로 보 내 고 빈 칸 이 라면 + 로 변환 합 니 다. 중국어 / 다른 문자 라면 BASE 64 로 문자열 을 암호 화 합 니 다. 예 를 들 어% E4% BD% A0% E5% A5% BD, 그 중% XX 의 XX 는 XX 입 니 다.이 기호 가 16 진법 으로 표 시 된 ASCII.
POST 제출: 제출 한 데 이 터 를 HTTP 패키지 의 패키지 < request - body > 에 배치 합 니 다. 상기 예제 에서 빨간색 글꼴 은 실제 전송 데이터 라 고 표시 되 어 있 습 니 다.
따라서 GET 가 제출 한 데 이 터 는 주소 표시 줄 에 표시 되 지만 POST 가 제출 하면 주소 표시 줄 이 바 뀌 지 않 습 니 다.
2. 전송 데이터 의 크기:
먼저 HTTP 프로 토 콜 은 전 송 된 데이터 크기 를 제한 하지 않 았 으 며 HTTP 프로 토 콜 규범 도 URL 길 이 를 제한 하지 않 았 습 니 다. 실제 개발 에 존재 하 는 제한 은 다음 과 같 습 니 다.
GET: 특정 브 라 우 저 와 서버 는 URL 길이 에 제한 이 있 습 니 다. 예 를 들 어 IE 는 URL 길이 에 대한 제한 이 2083 바이트 (2K + 35) 입 니 다. 다른 브 라 우 저, 예 를 들 어 Netscape, FireFox 등 은 이론 적 으로 길이 제한 이 없고 그 제한 은 운영 체제 의 지원 에 달 려 있 습 니 다.
따라서 GET 제출 시 전송 데 이 터 는 URL 길이 에 제한 을 받는다.
POST: URL 을 통 해 값 을 전달 하 는 것 이 아니 기 때문에 이론 적 으로 데이터 가 제한 되 지 않 습 니 다. 그러나 실제 각 WEB 서버 는 post 제출 데이터 의 크기 를 제한 하도록 규정 합 니 다. Apache, IIS 6 는 각각 설정 되 어 있 습 니 다.
3. 안전성:
POST 의 안전성 은 GET 의 안전성 보다 높 습 니 다. 주의: 여기 서 말 하 는 안전성 은 위 GET 에서 언급 한 '안전' 과 같은 개념 이 아 닙 니 다. 위의 '안전' 의 의 미 는 데이터 수정 을 하지 않 는 것 일 뿐 이 며, 여기 서 안전 한 의 미 는 진정한 보안 의 의미 입 니 다. 예 를 들 어 GET 를 통 해 데 이 터 를 제출 하면 사용자 이름과 비밀 번 호 는 URL 에 명문 화 됩 니 다. (1)로그 인 페이지 는 브 라 우 저 캐 시 될 수 있 습 니 다. (2) 다른 사람 이 브 라 우 저의 기록 을 보면 다른 사람 이 당신 의 계 정과 비밀 번 호 를 받 을 수 있 습 니 다.
이 내용에 흥미가 있습니까?
현재 기사가 여러분의 문제를 해결하지 못하는 경우 AI 엔진은 머신러닝 분석(스마트 모델이 방금 만들어져 부정확한 경우가 있을 수 있음)을 통해 가장 유사한 기사를 추천합니다:
리눅스 입문~컴퓨터 시스템의 하드웨어의 개요와 리눅스의 주요 기능과 그 구조의 개요~별도의 기사에서 각 Linux의 기능인 프로세스 및 메모리 관리 메커니즘에 대한 자세한 내용을 요약합니다. 입력 장치, 네트워크 어댑터를 통해 컴퓨터에서 처리를 수행하도록 요청 프로세스 관리 메모리 관리 장치 조작 ...
텍스트를 자유롭게 공유하거나 복사할 수 있습니다.하지만 이 문서의 URL은 참조 URL로 남겨 두십시오.
CC BY-SA 2.5, CC BY-SA 3.0 및 CC BY-SA 4.0에 따라 라이센스가 부여됩니다.