HTTP 프로토콜에 대한 깊은 이해
- 高洛峰원래의
- 2016-12-12 11:14:432135검색
HTTP 프로토콜에 대한 심층적인 이해
1. 기본 개념
1.1 소개
HTTP는 Hyper Text Transfer Protocol의 약자입니다. 이 개발은 HTTP/1.0 버전을 정의하는 RFC 1945 시리즈를 발표한 World Wide Web 컨소시엄과 IETF(Internet Engineering Task Force) 간의 협력의 결과입니다. 그 중 가장 유명한 것은 RFC 2616이다. RFC 2616은 오늘날 일반적으로 사용되는 버전인 HTTP 1.1을 정의합니다.
HTTP 프로토콜(HyperText Transfer Protocol, Hypertext Transfer Protocol)은 하이퍼텍스트를 WWW 서버에서 로컬 브라우저로 전송하는 데 사용되는 전송 프로토콜입니다. 브라우저를 더욱 효율적으로 만들고 네트워크 전송을 줄일 수 있습니다. 이는 컴퓨터가 하이퍼텍스트 문서를 정확하고 빠르게 전송하도록 보장할 뿐만 아니라 문서의 어느 부분이 전송되고 내용의 어느 부분이 먼저 표시되는지(예: 그래픽보다 텍스트) 등을 결정합니다.
HTTP는 요청과 응답으로 구성된 애플리케이션 계층 프로토콜이며 표준 클라이언트-서버 모델입니다. HTTP는 상태 비저장 프로토콜입니다.
1.2 TCP/IP 프로토콜 스택에서의 위치
HTTP 프로토콜은 일반적으로 TCP 프로토콜 위에 전달되며 때로는 TLS 또는 SSL 프로토콜 계층에서 수행됩니다. 우리는 종종 HTTPS에 대해 이야기합니다. 아래 그림과 같습니다.
기본 HTTP 포트 번호는 80, HTTPS 포트 번호는 443입니다.
1.3 HTTP 요청 응답 모델
HTTP 프로토콜은 항상 클라이언트에서 요청을 시작하고 서버에서 응답을 다시 보냅니다. 아래 그림을 참조하세요.
이는 HTTP 프로토콜의 사용을 제한하며 클라이언트가 요청을 시작하지 않을 때 서버가 클라이언트에 메시지를 푸시하는 것이 불가능합니다. .
HTTP 프로토콜은 상태 비저장 프로토콜입니다. 이 요청과 동일한 클라이언트의 마지막 요청 간에는 일치하지 않습니다.
1.4 워크플로
HTTP 작업을 트랜잭션이라고 하며 작업 프로세스는 4단계로 나눌 수 있습니다.
1) 먼저 클라이언트와 서버 연결을 설정해야 합니다. 하이퍼링크를 클릭하기만 하면 HTTP 작업이 시작됩니다.
2) 연결이 설정된 후 클라이언트는 서버에 요청을 보냅니다. 요청 형식은 URL(Uniform Resource Identifier), 프로토콜 버전 번호, 요청 수정자를 포함한 MIME 정보 및 클라이언트 정보입니다. . 및 가능한 콘텐츠입니다.
3) 요청을 받은 후 서버는 해당 응답 정보를 제공합니다. 형식은 정보의 프로토콜 버전 번호, 성공 또는 오류 코드와 서버 정보를 포함한 MIME 정보를 포함하는 상태 줄입니다. 및 엔터티 정보 및 가능한 콘텐츠.
4) 클라이언트는 서버가 반환한 정보를 받아 브라우저를 통해 사용자의 디스플레이에 표시한 후 서버와의 연결을 끊습니다.
위 과정 중 특정 단계에서 오류가 발생하면 해당 오류 메시지가 클라이언트에 반환되어 디스플레이 화면에 출력됩니다. 사용자의 경우 이러한 프로세스는 HTTP 자체에 의해 완료되며 사용자는 마우스로 클릭하고 정보가 표시될 때까지 기다리면 됩니다.
1.5 Wireshark를 사용하여 TCP 및 http 패킷 캡처
Wireshark를 열고 도구 모음에서 "캡처" -> "옵션"을 선택하면 인터페이스 선택이 그림 1과 같습니다.
일반 독자는 상단 드롭다운 상자를 선택하고 적절한 장치를 선택한 다음 "캡처 필터"를 클릭하면 됩니다. 여기서 선택하는 것은 "HTTP TCP 포트(80)"입니다. . 선택 후 위 그림에서 "시작"을 클릭하면 패킷 캡처가 시작됩니다.
예를 들어 브라우저에서 http://image.baidu.com/을 열고 그림 3과 같이 패킷을 캡처합니다.
http: // www.blogjava.NET/images/blogjava_net/amigoxie/40799/o_http%e5%8d%8f%e8%ae%ae%e5%ad%a6%e4%b9%a0-%e6%a6%82%e5 %bf %b5-3.jpg
위 그림에서 클라이언트 브라우저(ip는 192.168.2.33)와 서버 사이의 상호 작용 프로세스를 명확하게 볼 수 있습니다.
1) No1: 찾아보기 서버(192.168.2.33)가 서버(220.181.50.118)에 연결 요청을 보냅니다. 이는 TCP three-way handshake의 첫 번째 단계로 그림에서 알 수 있듯이 SYN, seq: 192.168.2.33) 요청이며 이때 확인이 필요합니다: SYN, ACK, 이때 seq: y. (y는 0), ACK: x+1(1).
3) No3: 브라우저(192.168.2.33)가 서버(220.181.50.118)에 확인 응답을 하여 연결에 성공했습니다. is: ACK, 이때 seq: x+1(is 1), ACK: y+1(is 1). 이는 3방향 핸드셰이크의 세 번째 단계입니다.
4) No4: 브라우저(192.168.2.33)가 페이지 HTTP 요청을 보냅니다.
5) No5: 서버(220.181. 50.118) 확인
6) No6: 서버(220.181.50.118)가 데이터를 보냅니다.
7) No7: 클라이언트 브라우저(192.168.2.33)가 확인합니다. No14: 클라이언트(192.168.2.33)가 이미지 HTTP 요청을 보냅니다.
9) No15: 서버(220.181.50.118)가 상태 응답 코드 200 OK
… 🎜>1.6 헤더 필드
각 헤더 필드는 도메인 이름, 콜론(:), 도메인 값으로 구성됩니다. 도메인 이름은 대소문자를 구분하지 않습니다. 필드 값 앞에 공백을 얼마든지 추가할 수 있으며, 각 줄의 시작 부분에 최소한 하나의 공백이나 탭을 사용하여 여러 줄로 확장할 수 있습니다.
패킷 캡처 사진에서 14번을 클릭하면 그림 4를 볼 수 있습니다.
http://www.blogjava.net/images/blogjava_net/amigoxie/40799/o_http%e5% 8d%8f%e8% ae%ae%e5%ad%a6%e4%b9%a0-%e6%a6%82%e5%bf%b5-4.jpg 응답 메시지
그림 5의 호스트 동작:
1.6.2 Referer 헤더 필드
Referer 헤더 필드를 사용하면 클라이언트가 소스를 지정할 수 있습니다. 서버가 로그인, 캐시 최적화 등에 사용할 수 있는 롤백 목록을 생성할 수 있도록 하는 요청 uri의 리소스 주소입니다. 또한 유지 관리 목적으로 중단되거나 결함이 있는 연결을 추적할 수 있습니다. 요청된 URI에 자체 URI 주소가 없으면 리퍼러를 보낼 수 없습니다. 부분 URI 주소가 지정된 경우 이 주소는 상대 주소여야 합니다.
그림 4에서 Referer 줄의 내용은 다음과 같습니다.
1.6.3 User-Agent 헤더 필드
User- 에이전트 헤더 필드 요청한 사용자에 대한 정보가 포함됩니다.
그림 4에서 User-Agent 줄의 내용은 다음과 같습니다.
Cache-Control은 요청과 응답이 뒤따르는 캐싱 메커니즘을 지정합니다. 요청 메시지 또는 응답 메시지에서 Cache-Control을 설정해도 다른 메시지를 처리하는 동안 캐싱 프로세스가 수정되지 않습니다. 요청 중 캐싱 지침에는 no-cache, no-store, max-age, max-stale, min-fresh, only-if-cached가 포함되며 응답 메시지의 지침에는 public, private, no-cache, no가 포함됩니다. -저장, 변환 없음, 재검증 필수, 프록시 재검증, 최대 수명.
그림 5의 헤더 필드는 다음과 같습니다.
날짜 헤더 필드는 전송된 메시지 시간을 나타냅니다. 시간의 설명 형식은 rfc822에 의해 정의됩니다. 예를 들어 날짜:월,200104년 12월 31일:25:57GMT입니다. Date에 기술된 시간은 세계 표준시를 나타냅니다. 이를 현지 시간으로 변환하려면 사용자의 시간대를 알아야 합니다.
그림 5에서 헤더 필드는 다음과 같습니다.
1.7 HTTP의 몇 가지 중요한 개념
1.7.1 연결: 연결
서로 통신하는 두 애플리케이션 사이에 구축되는 전송 계층의 실제 순환입니다.
http1.1에서는 요청 및 응답 헤더에 연결 헤더가 나타날 수 있습니다. 이 헤더의 의미는 클라이언트와 서버가 통신할 때 긴 링크를 처리하는 방법입니다.
http1.1에서는 클라이언트와 서버가 기본적으로 긴 링크를 지원합니다. 클라이언트가 http1.1 프로토콜을 사용하지만 긴 링크를 사용하지 않으려면 헤더에 연결 값을 지정해야 합니다. .close; 서버가 긴 링크를 지원하지 않으려면 응답에서 연결 값이 닫혀 있음을 명확하게 명시해야 합니다. 요청 또는 응답 헤더에 close 값이 있는 연결이 포함되어 있는지 여부는 해당 날짜에 요청이 처리된 후 현재 사용 중인 TCP 링크의 연결이 끊어진다는 것을 나타냅니다. 앞으로는 클라이언트가 새 요청을 할 때 새 TCP 링크를 생성해야 합니다.
1.7.2 메시지: 메시지
8-튜플의 구조화된 시퀀스를 포함하고 연결을 통해 전송되는 HTTP 통신의 기본 단위입니다.
1.7.3 요청: 요청
클라이언트에서 서버로의 요청 정보에는 리소스에 적용되는 메소드, 리소스의 식별자, 프로토콜의 버전 번호가 포함됩니다.
1.7.4 응답: 응답
HTTP 프로토콜의 버전 번호, 요청 상태(예: "성공" 또는 "찾을 수 없음")를 포함하여 서버에서 반환된 메시지 그리고 문서의 MIME 유형입니다.
1.7.5 리소스: 리소스
URI로 식별되는 네트워크 데이터 개체 또는 서비스입니다.
1.7.6 엔터티: 엔터티
요청 또는 응답 메시지에 포함될 수 있는 데이터 자원 또는 서비스 자원의 반영을 특수하게 표현하는 방법입니다. 엔터티에는 엔터티 헤더 정보와 엔터티 자체 콘텐츠가 포함됩니다.
1.7.7 클라이언트: 클라이언트
요청 전송을 목적으로 연결을 설정하는 애플리케이션입니다.
1.7.8 사용자 에이전트: UserAgent
요청 클라이언트를 초기화합니다. 이는 브라우저, 편집기 또는 기타 사용자 도구입니다.
1.7.9 서버: 서버
연결을 수락하고 요청에 대한 정보를 반환하는 애플리케이션입니다.
1.7.10 Origin Server: Originserver
는 특정 리소스가 상주하거나 생성될 수 있는 서버입니다.
1.7.11 프록시: 프록시
다른 클라이언트에 대한 요청을 설정하기 위해 서버 또는 클라이언트 역할을 할 수 있는 중간 프로그램입니다. 요청은 가능한 번역을 통해 내부적으로 또는 다른 서버를 통해 전달됩니다. 프록시는 요청 메시지를 보내기 전에 요청 메시지를 해석하고 가능하면 다시 작성해야 합니다.
프록시는 방화벽을 통해 클라이언트를 위한 포털 역할을 하는 경우가 많습니다. 프록시는 사용자 에이전트가 완료하지 않은 프로토콜을 통한 요청을 처리하는 도우미 애플리케이션 역할도 할 수 있습니다.
1.7.12 게이트웨이: 게이트웨이
다른 서버를 중개하는 역할을 하는 서버입니다. 프록시와 달리 게이트웨이는 요청된 리소스에 대한 원본 서버인 것처럼 요청을 수락합니다. 요청 클라이언트는 자신이 게이트웨이를 처리하고 있다는 사실을 인식하지 못합니다.
게이트웨이는 방화벽을 통해 서버 측 포털 역할을 하는 경우가 많습니다. 게이트웨이는 HTTP가 아닌 시스템에 저장된 리소스에 액세스하기 위한 프로토콜 변환기 역할도 할 수 있습니다.
1.7.13 채널: 터널
은 두 연결 사이의 중계 역할을 하는 중개 프로그램입니다. 일단 활성화되면 채널은 HTTP 요청에 의해 시작될 수 있지만 HTTP 통신에 속하는 것으로 간주되지 않습니다. 릴레이된 연결의 양쪽 끝이 닫히면 채널이 사라집니다. 채널은 포털이 반드시 존재해야 하거나 중개자가 릴레이된 트래픽을 해석할 수 없는 경우에 자주 사용됩니다.
1.7.14 캐시: 캐시
응답 정보를 로컬에 저장합니다.
부록: 참고 자료
"http_Baidu Encyclopedia": http://baike.baidu.com/view/9472.htm
"결과 인코딩 및 http 상태 응답 코드": http://blog.tieniu1980.cn/archives/377
"TCP의 3방향 핸드셰이크 분석":
http://cache.baidu.com/ c?m=9f65cb4a8c8507ed4fece763104c8c711923d030678197027fa3c215cc7905141130a8e5747e0d548d98297a5ae91e03f7f63772315477e3cacdd94cdbbdc42225d82c36734f844315c419d891007a9f34d507a9f916a2e1b065d2f48193864353bb15543897f1fb4d711edd1b86033093b1e94e022e67adec40728e2e605f983431c5508fe4&p=c6769a46c5820efd08e2973b42&user=baidu
《使用Wireshark来检测一次HTTP连接过程》：
http://blog.163.com/wangbo_tester/blog/static/12806792120098174162288/
"http 프로토콜의 몇 가지 중요한 개념": http://nc.mofcom.gov.cn/news/10819972.html
"http 프로토콜에서 연결 헤더의 역할 ":
http://blog.csdn.net/barfoo/archive/2008/06/05/2514667.aspx
2. 프로토콜에 대한 자세한 설명
2.1 /1.0과 HTTP/1.1의 HTTP 비교
RFC 1945는 HTTP/1.0 버전을 정의하고, RFC 2616은 HTTP/1.1 버전을 정의합니다.
저자는 내 블로그에 이 두 RFC의 중국어 버전 다운로드 주소를 제공합니다.
RFC1945 다운로드 주소:
http://www.blogjava.Net/Files/amigoxie/RFC1945(HTTP) 중국어 버전.rar
RFC2616 다운로드 주소:
http://www.blogjava.net/Files/amigoxie/RFC2616 (HTTP) 중국어 버전.rar
2.1.1 연결 설정
요청당 HTTP/1.0 A 새로운 TCP 연결을 설정해야 하며 해당 연결은 재사용할 수 없습니다. HTTP/1.1 이전 요청에 의해 설정된 TCP 연결 위에 새 요청을 보낼 수 있으며 연결을 재사용할 수 있습니다. 장점은 반복되는 TCP 3방향 핸드셰이크의 오버헤드를 줄이고 효율성을 향상시키는 것입니다.
참고: 동일한 TCP 연결에서 새 요청은 전송되기 전에 마지막 요청이 응답을 받을 때까지 기다려야 합니다.
2.1.2 호스트 도메인
HTTP1.1에는 요청 메시지 헤더에 추가 호스트 도메인이 있지만 HTTP1.0에는 이 도메인이 없습니다.
예:
GET /pub/WWW/TheProject.html HTTP/1.1
호스트: www.w3.org
아마도 HTTP1.0 It TCP 연결을 설정할 때 IP 주소가 지정되었으며 이 IP 주소에는 호스트가 하나만 있다고 믿는 경우가 있습니다.
2.1.3 날짜 및 시간 스탬프
(수신 방향)
HTTP1.0이든 HTTP1.1이든 다음 세 가지 날짜를 구문 분석할 수 있어야 합니다. /타임 스탬프:
1994년 11월 6일 일요일 08:49:37 GMT ; RFC 1123에 의해 업데이트됨
94년 11월 6일 일요일 08:49:37 GMT RFC 850; RFC 1036
Sun Nov 6 08:49:37 1994 ; ANSI C의 asctime() 형식
(전송 방향)
HTTP1.0에서는 세 번째 asctime 형식 날짜/시간이 필요합니다. 스탬프를 생성할 수 없습니다.
HTTP1.1에서는 RFC 1123(첫 번째) 형식의 날짜/시간 스탬프만 생성되어야 합니다.
2.1.4 상태 응답 코드
상태 응답 코드 100(계속) 상태 코드를 사용하면 클라이언트는 요청 메시지 본문을 보내기 전에 요청 헤더로 서버를 테스트하여 무엇을 확인할 수 있습니다. 서버가 요청 본문을 보낼지 여부를 결정하기 전에 요청 본문을 받지 마십시오.
클라이언트에는
Expect: 100-continue
가 포함됩니다. 서버가 이를 확인한 후 상태 코드 100(Continue)을 반환하면 클라이언트는 요청 본문 보내기를 계속합니다. . 이는 HTTP1.1에서만 사용할 수 있습니다.
또한 HTTP/1.1에는 101, 203, 205 등의 상태 응답 코드도 추가됩니다.
2.1.5 요청 방법
HTTP1.1에는 OPTIONS, PUT, DELETE, TRACE, CONNECT 이 요청 메소드.
메소드 = "OPTIONS" ; 섹션 9.2
"GET" 섹션 9.3
~ 🎜>
| 확장 방법 확장 방법 = 토큰2.2 HTTP 요청 메시지 2.2. 1 요청 메시지 형식 요청 메시지 형식은 다음과 같습니다. 요청 라인일반 정보 헤더 | 요청 헤더|엔티티 헤더CRLF(캐리지 줄 바꿈 반환)엔티티 콘텐츠"요청 줄"은 다음과 같습니다. 요청 줄 = 메서드 [공백] 요청 URI [공백] 버전 번호 [입력 및 줄 바꿈]요청 줄 예:Eg1:GET /index.html HTTP/1.1 Eg2:POST http://192.168.2.217 :8080/index.jsp HTTP/1.1HTTP 요청 메시지 예:GET /hello.htm HTTP/1.1
수락: */*수락- 언어: zh-cn
수락-인코딩: gzip, deflateIf-수정-이후: Wed, 17 Oct 2007 02:15:55 GMT
If- None-Match: W/"158-1192587355000 "사용자 에이전트: Mozilla/4.0(호환; MSIE 6.0; Windows NT 5.1; SV1)
호스트: 192.168.2.162:8080연결: Keep-Alive
2.2.2 요청 방법
HTTP 요청 방법에는 다음이 포함됩니다.
q GET
q POST
q HEAD
ETag: W/"158-1192590101000"
최종 수정: 2007년 10월 17일 수요일 03:01:41 GMT콘텐츠 유형: text/html
콘텐츠 길이: 158날짜: 2007년 10월 17일 수요일 03:01:59 GMT
서버: Apache-Coyote/1.1 2.3.2 http 상태 응답 코드2.3.2.1 1**: 요청 수신, 계속 처리
100 - 고객이 계속 요청해야 함
101——클라이언트는 요청에 따라 HTTP 프로토콜 버전을 변환하는 서버
2.3.2.2 2**: 작업이 성공적으로 수신, 분석 및 수락되었습니다.
201 ——새 파일의 URL을 알려달라는 메시지
202——수락하고 처리하지만 처리가 완료되지 않습니다
203——반환 정보가 불확실하거나 불완전합니다
204— —요청을 받았지만 반환 정보가 비어 있었습니다.
205 — 서버가 요청을 완료했으며 사용자 에이전트는 현재 탐색된 파일을 재설정해야 합니다.
206 — 서버 일부 사용자에 대한 요청을 완료했습니다 GET 요청
300 - 요청한 리소스를 여러 위치에서 사용할 수 있습니다.
301 - 요청 데이터 삭제
302 - 요청 데이터가 다른 주소에서 발견되었습니다.
303— — 다른 URL이나 접속 방법을 이용하시는 것을 권장합니다.
304 - 클라이언트가 GET을 수행했지만 파일은 변경되지 않았습니다.
305 - 요청한 리소스는 지정된 주소에서 얻어야 합니다. 서버
306——이전 버전의 HTTP에서 사용된 코드가 현재 버전에서는 더 이상 사용되지 않습니다
307——요청한 리소스를 일시적으로 삭제한다고 선언
2.3.2.4 4** : 요청에 잘못된 구문이 포함되어 있거나 완료할 수 없습니다.
400 - 구문 오류 등 잘못된 요청
401 - 승인되지 않음
HTTP 401.1 - 무단: 로그인 실패
HTTP 401.2 - 무단: 서버 구성 문제로 인해 로그인 실패
HTTP 401.3 - ACL이 리소스에 대한 액세스를 금지합니다
HTTP 401.4 - 무단: 승인이 거부되었습니다. 필터별
HTTP 401.5 - 승인되지 않음: ISAPI 또는 CGI 인증 실패
402 - 유효한 ChargeTo 헤더 응답 유지
403 - 액세스 금지
HTTP 403.1 액세스 금지: 실행 가능 액세스 없음
HTTP 403.2 - 액세스 없음: 읽기 액세스 없음
HTTP 403.3 - 액세스 없음: 쓰기 액세스 없음
HTTP 403.4 - 액세스 없음: SSL 필요
HTTP 403.5 - 금지: SSL 128 필요
HTTP 403.6 - 금지: IP 주소 거부
HTTP 403.7 - 금지: 클라이언트 인증서 필요
HTTP 403.8 - 금지: 사이트 접근이 금지됩니다
HTTP 403.9 - 금지: 연결된 사용자가 너무 많습니다
HTTP 403.10 - 금지: 잘못된 구성
HTTP 403.11 - 접근 금지: 비밀번호가 변경되었습니다
HTTP 403.12 - 금지: 매퍼에 의해 액세스 거부
HTTP 403.13 - 금지: 클라이언트 인증서가 취소되었습니다.
HTTP 403.15 - 금지: 클라이언트 액세스 권한이 너무 많습니다
HTTP 403.16 - 액세스 금지: 클라이언트 인증서를 신뢰할 수 없거나 유효하지 않습니다.
HTTP 403.17 - 액세스 금지: 클라이언트 인증서가 만료되었거나 아직 유효하지 않습니다.
404— — 파일, 쿼리 또는 발견된 URL
405 — 사용자가 요청 라인 필드에 정의한 메서드는 허용되지 않습니다.
406 — 사용자가 보낸 수락 드래그에 따라 요청한 리소스에 액세스할 수 없습니다.
407 - 401과 유사하게, 사용자는 먼저 프록시 서버에서 승인을 받아야 합니다.
408 - 클라이언트가 사용자가 지정한 시간 내에 요청을 완료하지 않았습니다.
409 - 예 현재 리소스 상태, 요청을 완료할 수 없음
410 - 이 리소스는 더 이상 서버에 존재하지 않으며 추가 참조 주소도 없습니다.
411 - 서버가 사용자 정의 Content-Length를 거부합니다. 속성 요청
412 - 현재 요청에서 하나 이상의 요청 헤더 필드가 잘못되었습니다.
413 - 요청한 리소스가 서버에서 허용하는 크기보다 큽니다.
414 - 요청한 리소스 URL이 서버에서 허용하는 길이보다 깁니다.
415 - 요청한 리소스가 요청 항목 형식을 지원하지 않습니다.
416 - 요청에 Range 요청 헤더 필드가 포함되어 있고 거기에 현재 요청 리소스 범위 내에 범위 표시 값이 없으며 요청에 If-Range 요청 헤더 필드가 포함되어 있지 않습니다.
417 - 서버가 요청 Expect 헤더 필드에 지정된 기대치를 충족하지 않습니다. 프록시 서버인 경우 다음 단계 서버가 요청 길이를 충족하지 못할 수도 있습니다.
2.3.2.5 5**: 서버가 완전히 유효한 요청을 수행하지 못했습니다.
HTTP 500 - 내부 서버 오류
HTTP 500.100 - 내부 서버 오류 - ASP 오류
HTTP 500-11 서버 다운
HTTP 500-12 애플리케이션 재시작됨
HTTP 500-13 - 서버 사용량이 너무 많음
HTTP 500-14 - 애플리케이션이 유효하지 않음
HTTP 500-15 - 요청이 허용되지 않음 global.asa
오류 501 - 구현되지 않음
HTTP 502 - 게이트웨이 오류
2.4 텔넷 http 테스트 사용
Windows에서는 명령 창을 사용하여 간단한 http 테스트를 수행할 수 있습니다.
cmd를 입력하여 명령 창으로 들어가 명령줄에 다음 명령을 입력하고 Enter를 누릅니다.
telnet www.baidu.com 80
그런 다음 "Ctrl+ ]를 누릅니다. "를 입력한 다음 Enter 키를 눌러 반환된 결과를 에코합니다.
그런 다음 요청 메시지 보내기를 시작합니다. 예를 들어 Baidu 홈페이지 메시지를 요청하려면 다음 요청 메시지를 보냅니다. 사용되는 HTTP 프로토콜은 HTTP/1.1입니다.
GET /index.html HTTP/1.1
참고: 위 메시지를 명령 창에 복사한 후 응답 메시지를 받으려면 캐리지 리턴과 줄 바꿈을 두 번 눌러야 합니다. HTTP 프로토콜에 필요한 명령입니다. 두 번째는 입력을 확인하고 요청을 보내는 것입니다.
아래 그림과 같이 200 OK 메시지가 반환되는 것을 확인할 수 있습니다.
HTTP/1.1을 사용하면, 연결이 되지 않았습니다. 요청이 완료된 후 연결이 끊어졌습니다. HTTP1.0을 사용하는 경우 명령 창에
GET /index.html HTTP/1.0
을 입력합니다.이때 요청이 종료된 후 바로 연결이 끊어지는 것을 확인할 수 있습니다.
독자는 GET 또는 POST를 사용할 때 헤더 도메인 정보를 가져오려고 시도할 수도 있습니다. 예를 들어 다음 정보를 입력합니다.
GET /index.html HTTP/1.1
connection: close
Host: www.baidu.com
2.5 일반적인 요청 방식
일반적인 요청 방식은 GET과 POST가 있습니다.
l GET 방식: 엔터티 정보 형태로 획득 요청 URI가 단지 데이터 생성 프로세스인 경우 응답 엔터티에서 결국 반환되는 것은 처리 프로세스에 대한 설명이 아니라 처리 프로세스의 결과가 가리키는 리소스입니다.
l POST 메서드: 대상 서버에 요청을 보내는 데 사용되며, 요청에 첨부된 엔터티를 수락하고 이를 요청 URI에 지정된 리소스의 새로운 추가 하위 항목으로 처리하도록 요구합니다. 요청 큐는 다음 기능을 달성하기 위해 통일된 방법을 사용하도록 설계되었습니다.
1: 기존 리소스 해석
2: 전자 게시판, 뉴스 그룹, 메일링 리스트에 정보 보내기 또는 유사한 토론 그룹
3: 데이터 블록 제출
4: 추가 작업을 통해 데이터베이스를 확장합니다.
위 설명에서 볼 수 있듯이 Get은 서버에 데이터를 요청하는 것이고 Post는 서버에 데이터를 제출하라는 요청입니다. 제출할 데이터는 정보 헤더 뒤의 엔터티에 있습니다. .
GET 메소드와 POST 메소드는 다음과 같은 차이점이 있습니다.
(1) 클라이언트 측에서 Get 메소드는 URL을 통해 데이터를 제출하며 해당 데이터는 URL에서 볼 수 있습니다. POST 방식을 사용하면 데이터가 HEADER 내의 HTML 제출에 배치됩니다.
(2) GET으로 제출된 데이터는 최대 1024바이트까지만 가능하지만 POST에는 이 제한이 없습니다.
(3) 보안 문제. (1)에서 설명한 것처럼 Get을 사용하면 주소 표시줄에 매개변수가 표시되지만 Post는 표시되지 않습니다. 따라서 데이터가 중국어 데이터이고 민감하지 않은 데이터인 경우 get을 사용하고, 사용자가 입력한 데이터가 중국어가 아니고 민감한 데이터를 포함하는 경우 post를 사용하는 것이 좋습니다.
(4) 안전하고 멱등성입니다. 안전하다는 것은 정보를 수정하는 대신 정보를 얻는 데 작업이 사용된다는 의미입니다. 멱등성은 동일한 URL에 대한 여러 요청이 동일한 결과를 반환해야 함을 의미합니다. 완전한 정의는 보이는 것만큼 엄격하지 않습니다. 즉, GET 요청에는 일반적으로 부작용이 없어야 합니다. 기본적으로 목표는 사용자가 링크를 열 때 자신의 관점에서 리소스가 변경되지 않았음을 확신할 수 있도록 하는 것입니다. 예를 들어, 뉴스 사이트의 첫 페이지는 지속적으로 업데이트됩니다. 두 번째 요청은 다른 배치의 뉴스를 반환하지만 작업은 항상 현재 뉴스를 반환하므로 여전히 안전하고 멱등성 있는 것으로 간주됩니다. 그 반대. POST 요청은 그렇게 쉽지 않습니다. POST는 서버의 리소스를 변경할 수 있는 요청을 나타냅니다. 여전히 뉴스 사이트를 예로 들면, 기사에 대한 독자의 주석은 POST 요청을 통해 구현되어야 합니다. 왜냐하면 주석이 제출된 후 사이트가 다르기 때문입니다(예: 주석이 기사 아래에 표시됨).
2.6 요청 헤더
가장 일반적인 HTTP 요청 헤더는 다음과 같습니다.
l 수락: 브라우저에서 허용되는 MIME 유형
l Accept-Charset: 브라우저에 허용되는 문자 집합
l Accept-Encoding: gzip과 같이 브라우저가 디코딩할 수 있는 데이터 인코딩 방법입니다. 서블릿은 gzip으로 인코딩된 HTML 페이지를 gzip을 지원하는 브라우저에 반환할 수 있습니다. 대부분의 경우 다운로드 시간을 5~10배까지 줄일 수 있습니다.
l Accept-Language: 브라우저가 원하는 언어 유형, 서버가 둘 이상의 언어 버전을 제공할 수 있는 경우 사용됩니다.
l 인증: 인증 정보는 일반적으로 서버에서 보낸 WWW-Authenticate 헤더에 대한 응답에 나타납니다.
l 연결: 지속적인 연결이 필요한지 여부를 나타냅니다. 서블릿이 여기의 값을 "Keep-Alive"로 확인하거나 요청이 HTTP 1.1을 사용하고 있음을 확인하는 경우(HTTP 1.1은 기본적으로 영구 연결을 만듭니다) 페이지에 여러 요소(예: Applet, 그림)을 통해 다운로드에 소요되는 시간을 대폭 단축할 수 있습니다. 이를 달성하려면 Servlet이 응답에 Content-Length 헤더를 보내야 합니다. 가장 간단한 구현 방법은 먼저 콘텐츠를 ByteArrayOutputStream에 쓴 다음 공식적으로 콘텐츠를 쓰기 전에 해당 크기를 계산하는 것입니다. -길이: 요청 메시지 본문의 길이를 나타냅니다.
l 쿠키: 가장 중요한 요청 헤더 정보 중 하나입니다.
l 보낸 사람: 요청을 보낸 사람의 이메일 주소입니다. 웹 클라이언트 프로그램에서 사용하는 일부 특수 기능은 브라우저에서 사용하지 않습니다.
l 호스트: 초기 URL의 호스트 및 포트
l If-Modified-Since: 요청된 콘텐츠가 지정된 날짜 이후 수정된 경우에만 반환하고, 그렇지 않으면 304 "수정되지 않음"을 반환합니다. "응답;
l Pragma: "no-cache" 값을 지정하면 프록시 서버이고 이미 페이지의 로컬 복사본이 있는 경우에도 서버가 새로 고친 문서를 반환해야 함을 의미합니다.
l 리퍼러: 사용자가 현재 요청된 페이지에 액세스하는 URL을 포함합니다.
l User-Agent: 브라우저 유형. 이 값은 서블릿에서 반환된 콘텐츠가 브라우저 유형과 관련된 경우 매우 유용합니다.
l UA-Pixels, UA-Color, UA- OS, UA-CPU: 일부 버전의 IE 브라우저에서 전송되는 비표준 요청 헤더로, 화면 크기, 색상 깊이, 운영 체제 및 CPU 유형을 나타냅니다.
2.7 응답 헤더
가장 일반적인 HTTP 응답 헤더는 다음과 같습니다.
l 허용: 서버에서 지원하는 요청 방법(예: GET, POST, 등);
l Content-Encoding: 문서의 인코딩(Encode) 방법입니다. 디코딩 후에만 Content-Type 헤더에 지정된 콘텐츠 유형을 얻을 수 있습니다. gzip을 사용하여 문서를 압축하면 HTML 문서의 다운로드 시간을 크게 줄일 수 있습니다. Java의 GZIPOutputStream은 쉽게 gzip 압축을 수행할 수 있지만 Unix의 Netscape와 Windows의 IE 4 및 IE 5만이 이를 지원합니다. 따라서 서블릿은 Accept-Encoding 헤더(예: request.getHeader("Accept-Encoding"))를 확인하여 브라우저가 gzip을 지원하는지 확인하고, gzip을 지원하는 브라우저에 대해 gzip으로 압축된 HTML 페이지를 반환하고, 일반 헤더를 반환해야 합니다. 기타 브라우저용 HTML 페이지
l Content-Length: 콘텐츠 길이를 나타냅니다. 이 데이터는 브라우저가 지속적인 HTTP 연결을 사용하는 경우에만 필요합니다. 지속적인 연결을 활용하려면 출력 문서를 ByteArrayOutputStream에 작성하고 완료 시 크기를 확인한 다음 값을 Content-Length 헤더에 입력하고 마지막으로 byteArrayStream.writeTo(response.getOutputStream()을 통해 콘텐츠를 보낼 수 있습니다. );
l Content-Type: 다음 문서가 속하는 MIME 유형을 나타냅니다. 서블릿의 기본값은 text/plain이지만 일반적으로 Content-Type이 설정되어 있으므로 명시적으로 지정해야 합니다. , HttpServletResponse는 전용 메소드 setContentTyep을 제공합니다. 확장과 MIME 유형 간의 대응은 web.xml 파일에서 구성할 수 있습니다.
l 날짜: setDateHeader를 사용하여 이 헤더를 설정할 수 있습니다. 문제: -Since 요청 헤더는 날짜를 제공하며 요청은 수정 시간이 지정된 시간보다 이후인 문서만 반환됩니다. ) 상태가 반환됩니다. setDateHeader 메소드로 설정할 수도 있습니다. ;
l 위치: 고객이 문서를 검색하기 위해 가야 할 위치를 나타냅니다. 위치는 일반적으로 직접 설정되지 않고 sendRedirect 메소드를 통해 설정됩니다. 상태 코드를 302로 설정하는 HttpServletResponse;
l 새로 고침: 브라우저가 문서를 새로 고쳐야 하는 시간(초)을 나타냅니다. 또한 setHeader( "Refresh", "5; URL=http://host/path"). 서버는 지정된 페이지를 읽습니다. 이 기능은 일반적으로 가 있습니다. CGI나 Servlet을 사용할 수 없는 HTML Writer에게는 자동 새로 고침이나 리디렉션이 매우 중요하기 때문입니다. 그러나 Servlet의 경우 Refresh 헤더를 직접 설정하는 것이 더 편리합니다. 새로 고침의 의미는 "이 페이지를 새로 고치거나 N초마다 지정된 페이지에 액세스"가 아니라 "이 페이지를 새로 고치거나 N초 후에 지정된 페이지에 액세스"라는 의미입니다. 따라서 지속적인 새로 고침을 위해서는 매번 새로 고침 헤더를 보내야 하며, 204 상태 코드를 보내면 브라우저가 새로 고침 헤더를 사용하든 를 사용하든 새로 고침을 계속하지 못하게 될 수 있습니다. Refresh 헤더는 공식 HTTP 1.1 사양의 일부가 아니라 확장이지만 Netscape와 IE 모두 이를 지원합니다.
2.8 엔터티 헤더
엔티티 헤더는 엔터티 콘텐츠의 메타 정보를 사용하여 엔터티 정보 유형, 길이, 압축 방법, 마지막 수정 시간, 그리고 데이터 유효성을 기다리세요.
l 허용: GET,POST
l 콘텐츠 인코딩: 문서의 인코딩(인코드) 방법(예: gzip, "2.5 응답 헤더" 참조)
l 콘텐츠 -Language: 콘텐츠의 언어 유형, 예: zh-cn;
l Content-Length: 콘텐츠 길이를 나타냅니다. 예: 80, "2.5 응답 헤더"를 참조하세요. 🎜>l Content-Location: 클라이언트가 문서를 검색하기 위해 어디로 가야 하는지를 나타냅니다. 예: http://www.dfdf.org/dfdf.html, "2.5 응답 헤더"를 참조하세요.
l Content-MD5: 체크섬으로 사용되는 MD5 엔터티의 MD5 다이제스트. 송신자와 수신자 모두 MD5 다이제스트를 계산하고 수신자는 계산된 값을 이 헤더에 전달된 값과 비교합니다. 예1: Content-MD5: . 예2: dfdfdfdfdfdfdff==;
l Content-Range: 일부 엔터티와 함께 전송되며 삽입된 바이트의 하위 및 상위 바이트 오프셋을 나타내며 이 엔터티의 전체 길이도 나타냅니다. Eg1: Content-Range: 1001-2000/5000, eg2: bytes 2543-4532/7898
l Content-Type: 보내거나 받는 엔터티의 MIME 유형을 나타냅니다. 예: text/html; charset=GB2312 기본 유형/하위 유형;
l 만료: 0은 캐싱이 없음을 나타냅니다.
l 마지막 수정 시간: 웹에서 고려하는 객체의 마지막 수정 시간 예를 들어 파일의 마지막 수정 시간, 동적 페이지의 마지막 생성 시간 등이 있습니다. 예: 최종 수정: 화요일, 2008년 5월 6일 02:42:43 GMT.
2.8 확장 헤더
HTTP 메시지에서 HTTP1.1 공식 사양 정의된 헤더 필드로, 이러한 헤더 필드를 통칭하여 사용자 정의 HTTP 헤더 또는 확장 헤더라고 하며 일반적으로 엔터티 헤더 유형으로 처리됩니다.
요즘 인기 있는 브라우저는 실제로 Cookie, Set-Cookie, Refresh 및 Content-Disposition과 같이 일반적으로 사용되는 여러 확장 헤더 필드를 지원합니다.
l 새로 고침: 1;url=http://www.dfdf.org //1초 후 지정된 위치로 이동
l Content-Disposition: 헤더 필드를 참조하세요. " 2.5 응답 헤더";
l Content-Type: 웹 서버는 브라우저에 응답하는 개체 유형을 알려줍니다.
eg1: 콘텐츠 유형: 애플리케이션/xml;
eg2: 애플리케이션/옥텟-스트림;
콘텐츠 처리: 파일 이름=aaa.zip
부록: 참고자료
"HTTP1.1과 HTTP1.0의 차이점":
http://blog.csdn.net/yanghehong/archive/2009/05/ 28 /4222594.aspx
"HTTP 요청(GET과 POST의 차이) 및 응답":
http://www.blogjava.net/honeybee/articles/164008.html
"Baidu가 알고 있는 HTTP 요청 헤더 개요":
http://zhidao.baidu.com/question/32517427.html
"엔티티 헤더 및 확장 헤더 ":
http://www.cnblogs.com/tongzhiyong/archive/2008/03/16/1108776.html
3. 심층 이해
3.1 쿠키와 세션
쿠키와 세션은 모두 상태 정보를 저장하는 데 사용됩니다. 둘 다 클라이언트 상태를 저장하는 메커니즘입니다. 둘 다 HTTP의 상태 비저장 문제를 해결하기 위한 노력입니다.
쿠키나 URL 쓰기 저장 메커니즘을 사용하여 세션을 구현할 수 있습니다. 쿠키를 사용하여 구현된 세션은 쿠키의 보다 발전된 응용이라고 볼 수 있습니다.
3.1.1 둘의 비교
Cookie와 Session은 다음과 같은 분명한 차이점이 있습니다.
1) Cookie는 상태를 클라이언트에 저장하고, Session은 상태를 클라이언트에 저장합니다. 서버 터미널
2) 쿠키는 서버가 로컬 컴퓨터에 저장하고 각 요청과 함께 동일한 서버로 전송되는 작은 텍스트 조각입니다. 쿠키는 RFC2109에서 처음 구현되었으며 이후 RFC2965에서 향상되었습니다. 웹 서버는 HTTP 헤더를 사용하여 클라이언트에 쿠키를 보냅니다. 클라이언트 터미널에서 브라우저는 이러한 쿠키를 구문 분석하여 로컬 파일에 저장합니다. 이 쿠키는 동일한 서버에 대한 모든 요청에 자동으로 첨부됩니다. 세션은 HTTP 프로토콜에 정의되어 있지 않습니다.
3) 세션은 각 사용자를 위한 것입니다. 변수의 값은 어떤 사용자 세션 변수인지 구별하는 데 사용됩니다. 클라이언트가 쿠키를 비활성화하면 브라우저가 이를 서버에 반환합니다.
4) 보안 측면에서: 사이트를 사용하여 세션에 액세스하고 자신의 컴퓨터에서 쿠키를 생성합니다. 서버 측의 SESSION 메커니즘은 고객이 저장한 정보를 임의로 읽지 않으므로 더 안전한 것이 좋습니다.
3.1.2 세션 메커니즘
세션 메커니즘은 서버측 메커니즘으로, 서버는 정보를 저장하기 위해 해시 테이블과 유사한 구조를 사용합니다(또는 해시 테이블을 사용할 수도 있음).
프로그램이 클라이언트 요청에 대한 세션을 생성해야 할 때 서버는 먼저 클라이언트의 요청에 이미 세션 ID라고 하는 세션 식별자가 포함되어 있는지 확인합니다. 이미 세션 ID가 포함되어 있으면 이전에 존재했음을 의미합니다. 클라이언트가 세션을 생성하면 서버는 세션 ID에 따라 세션을 검색하여 사용합니다(검색할 수 없는 경우 새 세션을 생성할 수 있음). 이 세션과 관련된 세션 ID가 생성됩니다. 세션 ID 값은 반복되지도 않고 위조할 패턴을 찾기도 쉽지 않은 문자열이어야 합니다. 이 응답의 저장을 위한 클라이언트입니다.
3.1.6 세션 구현
3.1.6.1 쿠키를 사용하여 구현
서버는 각 세션에 고유한 JSESSIONID를 할당하고 이를 쿠키를 통해 클라이언트에 보냅니다.
클라이언트가 새 요청을 시작하면 쿠키 헤더에 이 JSESSIONID가 포함됩니다. 이런 방식으로 서버는 클라이언트에 해당하는 Session을 찾을 수 있습니다.
프로세스는 아래 그림과 같습니다.
3.1.6.2 URL 에코를 사용하여
URL 쓰기 저장을 달성하려면 서버가 브라우저 페이지에 대한 모든 링크는 JSESSIONID 매개변수를 전달하므로 클라이언트가 링크를 클릭하면 JSESSIONID가 서버로 전송됩니다.
리소스를 요청하기 위해 브라우저에 서버 리소스의 URL을 직접 입력하면 세션이 일치하지 않습니다.
Tomcat의 세션 구현은 처음에 쿠키와 URL 쓰기 저장 메커니즘을 모두 사용합니다. 클라이언트가 쿠키를 지원하는 것으로 확인되면 계속해서 쿠키를 사용하고 URL 쓰기 저장 사용을 중지합니다. 쿠키가 비활성화된 경우 항상 URL 쓰기 저장을 사용하세요. JSP 개발에서 Session을 처리할 때 페이지의 링크에 대해 response.encodeURL()을 사용하는 것을 기억하세요.
3.1.3 J2EE 프로젝트에서 세션이 실패하는 여러 상황
1) 세션 타임아웃: 30분 등 지정된 시간 내에 세션이 만료되는 경우. 세션이 유효하지 않습니다. 예를 들어 web.xml에서 다음 설정이 이루어집니다.
>
q 네트워크 대역폭 소비 감소: 복제본을 재사용하면 클라이언트의 대역폭 소비가 줄어들고 고객은 대역폭 비용을 절감하고 대역폭 요구 사항 증가를 제어하며 관리를 더 쉽게 할 수 있습니다.
3.2.3 캐시 관련 HTTP 확장 메시지 헤더
q Expires: 응답 내용이 만료되는 시간을 의미, Greenwich Mean Time GMT
q Cache-Control: 더보기 캐시된 콘텐츠의 세부 제어
q Last-Modified: 응답의 리소스가 마지막으로 수정된 시간
q ETag: 응답의 리소스에 대한 고유한 검사 값 서버에서 특정 기간 동안 식별됩니다.
q 날짜: 서버 시간
q If-Modified-Since: 클라이언트가 액세스한 리소스가 마지막으로 수정된 시간으로 Last-Modified와 동일합니다.
q If-None-Match: 클라이언트가 액세스한 리소스의 확인 값으로 ETag와 동일합니다.
3.2.4 클라이언트 캐싱을 적용하기 위한 일반적인 프로세스
서버가 요청을 받으면 리소스의 Last-Modified 및 ETag 헤더를 200OK로 다시 보내고 클라이언트는 리소스를 캐시에 저장하고 이 두 가지 속성을 기록합니다. 클라이언트가 동일한 요청을 보내야 하는 경우 요청에 If-Modified-Since 및 If-None-Match라는 두 개의 헤더가 포함됩니다. 두 헤더의 값은 응답의 Last-Modified 및 ETag 헤더의 값입니다. 서버는 이 두 헤더를 통해 로컬 리소스가 변경되지 않았음을 확인하고 클라이언트는 이를 다시 다운로드할 필요가 없으며 304 응답을 반환합니다. 일반적인 프로세스는 아래 그림과 같습니다.
3.2.5 웹 캐싱 메커니즘
HTTP/1.1에서 캐싱의 목적은 전송 요청을 줄이는 것입니다. 대부분의 경우 완전한 응답을 보낼 필요가 없을 수도 있습니다. 전자는 네트워크 루프 수를 줄입니다. HTTP는 이러한 목적으로 "만료" 메커니즘을 활용합니다. 후자는 네트워크 애플리케이션의 대역폭을 줄입니다. HTTP는 이러한 목적으로 "검증" 메커니즘을 사용합니다.
HTTP는 3가지 캐싱 메커니즘을 정의합니다.
1) 신선도: 원본 서버에서 응답 메시지를 다시 확인할 수 있으며 서버와 클라이언트에서 제어할 수 있습니다. 예를 들어 Expires 응답 헤더는 문서를 사용할 수 없는 시간을 제공합니다. Cache-Control의 max-age 플래그는 최대 캐시 시간을 나타냅니다.
2) 유효성 검사: 캐시된 응답이 여전히 사용 가능한지 확인하는 데 사용됩니다. 예를 들어 응답에 Last-Modified 응답 헤더가 있는 경우 캐시는 상황에 따라 요청을 보낼지 여부를 결정하기 위해 If-Modified-Since를 사용할 수 있습니다. 3) 무효화(Invalidation): 캐시를 통한 또 다른 요청에서 가끔 부작용이 발생하는 경우가 종종 있습니다. 예를 들어, URL이 캐시된 응답과 연결되어 있지만 POST, PUT 및 DELETE 요청이 뒤따르면 캐시가 만료됩니다.
3.3 중단점 재개 및 다중 스레드 다운로드 구현 원칙
q HTTP 프로토콜의 GET 메소드는 리소스의 특정 부분만 요청하도록 지원합니다.
q 206 부분 콘텐츠; 부분 콘텐츠 응답
q 요청된 리소스 범위
q 콘텐츠 범위 응답 리소스 범위
q 연결이 끊어졌다가 다시 연결되면 클라이언트는 다운로드되지 않은 중단점 재개를 달성하기 위해 전체 리소스를 다시 요청하는 대신 리소스의 일부가 요청됩니다.
차단 요청 리소스 인스턴스:
Eg1: 범위: 바이트=306302-: 이 리소스를 306302바이트부터 끝까지 요청합니다.
Eg2: 콘텐츠- 범위: 바이트 306302 -604047/604048: 응답은 리소스의 바이트 306302-604047이 전달되고 리소스가 총 604048바이트임을 나타냅니다.
클라이언트는 동시 요청을 통해 동일한 리소스를 요청하는 데 사용됩니다. 특정 리소스의 동시 청크 다운로드를 구현합니다. 빠른 다운로드라는 목적을 달성하기 위해. 현재 인기 있는 FlashGet과 Thunder는 기본적으로 이 원리를 사용합니다.
멀티 스레드 다운로드 원칙:
q 다운로드 도구는 HTTP 요청을 발행하는 여러 스레드를 엽니다.
q 각 http 요청은 리소스 파일의 일부만 요청합니다. : 내용- 범위: 바이트 20000-40000/47000
q 각 스레드에서 다운로드한 파일을 병합합니다.
3.4 https 통신 프로세스
3.4.1 https
HTTPS(전체 이름: Hypertext Transfer Protocol over Secure Socket Layer)란 간단히 말해서 보안을 목표로 하는 HTTP 채널입니다. HTTP의 보안 버전입니다. 즉, HTTP에 SSL 레이어가 추가된 것입니다. HTTPS의 보안 기반은 SSL이므로 암호화에 대한 자세한 내용은 SSL을 참조하세요.
아래 그림 참고:
https에서 사용하는 포트 번호는 443입니다.
3.4.2 https 구현 원칙
기본적인 암호화 및 복호화 알고리즘 유형에는 두 가지가 있습니다.
1) 대칭 암호화: 키가 하나만 있고 암호화 및 복호화 알고리즘은 다음과 같습니다. 복호화는 동일한 비밀번호이며 암호화 및 복호화 속도가 빠릅니다. 일반적인 대칭 암호화 알고리즘에는 DES, AES 등이 포함됩니다.
2) 비대칭 암호화: 키가 쌍으로 나타납니다(개인 키는 유추할 수 없습니다). 공개키를 기반으로 하며, 개인키를 기반으로 개인키를 유추할 수 없음), 공개키를 유추할 수 없음), 암호화와 복호화는 서로 다른 키를 사용(공개키 암호화에는 개인키 복호화 필요, 개인키 암호화에는 공개키 복호화 필요) , 상대적 대칭 암호화는 속도가 느리며 일반적인 비대칭 암호화 알고리즘에는 RSA, DSA 등이 포함됩니다.
https 통신 과정을 살펴보겠습니다:
https 통신의 장점:
1) 클라이언트는 클라이언트일 뿐입니다.
2) 암호화된 데이터는 클라이언트와 서버에서 일반 텍스트로만 얻을 수 있습니다.
3) 클라이언트와 서버는 안전합니다.
3.5 http 프록시
3.5.1 http 프록시 서버
프록시 서버의 정식 영문명은 Proxy Server이며, 그 기능은 네트워크에 대한 프록시 역할을 하는 것입니다. 사용자는 네트워크 정보를 얻습니다. 비유적으로 말하면 네트워크 정보의 전송 스테이션입니다.
프록시 서버는 브라우저와 웹 서버 사이의 서버로, 브라우저가 웹 페이지를 검색하기 위해 웹 서버로 직접 이동하지 않고 요청 신호를 보냅니다. 먼저 프록시 서버로 전송되며, 프록시 서버는 브라우저에서 요구하는 정보를 검색하여 사용자의 브라우저로 보냅니다.
게다가 대부분의 프록시 서버에는 대용량 캐시와 마찬가지로 버퍼링 기능이 있습니다. 브라우저에서 요청한 데이터가 이미 존재하는 경우 새로 얻은 데이터를 자체 메모리에 지속적으로 저장합니다. 로컬 메모리에 있고 최신 상태이므로 웹 서버에서 데이터를 다시 가져오지 않고 메모리에 있는 데이터를 사용자 브라우저로 직접 전송하므로 브라우저 성능이 크게 향상됩니다. 그리고 효율성.
더 중요한 것은 프록시 서버(프록시 서버)는 인터넷 링크 수준 게이트웨이에서 제공하는 중요한 보안 기능으로 OSI(Open System Interconnection) 모델의 대화 계층에서 주로 작동한다는 것입니다.
3.5.2 http 프록시 서버의 주요 기능
주요 기능은 다음과 같습니다.
1) 자신의 IP 접속 제한을 뚫고 해외 사이트에 접속합니다. 예: Education Network 및 169 Network와 같은 인터넷 사용자는 프록시를 통해 외국 웹 사이트에 액세스할 수 있습니다.
2) 대학의 FTP와 같은 일부 단위 또는 그룹의 내부 리소스에 액세스합니다(프록시 주소가 다음 주소에 있는 경우). 리소스의 허용된 접근 범위) 내) 교육 네트워크의 주소 세그먼트에 있는 무료 프록시 서버를 사용하여 교육 네트워크에 공개된 다양한 FTP 다운로드 및 업로드는 물론 다양한 데이터 쿼리 및 공유 서비스에 사용할 수 있습니다. ;
3) 차이나 텔레콤의 IP 차단 돌파: 차이나 텔레콤 사용자는 많은 웹 사이트에 대한 액세스를 제한했으며, 이는 인위적인 것이며 서버마다 주소를 다르게 차단합니다. 따라서 접속할 수 없는 경우에는 외부 프록시 서버를 사용해 보세요.
4) 접속 속도 향상: 일반적으로 프록시 서버는 외부 정보가 전달되면 더 큰 하드 디스크 버퍼를 설정합니다. 다른 사용자가 동일한 정보에 다시 액세스하면 해당 정보를 버퍼에서 직접 꺼내어 사용자에게 전달하여 액세스 속도를 향상시킵니다.
5) 실제 IP 숨기기: 인터넷 사용자도 사용할 수 있습니다. 이 방법을 사용하면 IP를 숨기고 공격으로부터 자신을 보호할 수 있습니다.
3.5.3 http 프록시 아이콘
http 프록시 아이콘은 아래와 같습니다:
클라이언트 브라우저의 경우 http 프록시 서버는 서버와 동일합니다.
웹 서버의 경우 http 프록시 서버가 클라이언트 역할을 합니다.
3.6 가상 호스트 구현
3.6.1 가상 호스트란 무엇입니까
가상 호스트: 네트워크 서버에 일정량의 디스크 공간을 할당하여 사용자가 호스트할 수 있도록 합니다. 사이트 및 애플리케이션 구성 요소 등은 필요한 사이트 기능과 데이터 저장 및 전송 기능을 제공합니다.
'웹사이트 공간'이라고도 불리는 소위 가상 호스트는 인터넷에서 실행되는 서버를 여러 개의 '가상' 서버로 나누어 각각의 가상 호스트가 독립적인 도메인 이름과 완전한 인터넷 서버를 갖는 것입니다. (WWW, FTP, E-mail 등 지원) 기능. 서버의 다양한 가상 호스트는 독립적이며 사용자가 관리합니다. 그러나 서버 호스트는 특정 수의 가상 호스트만 지원할 수 있습니다. 이 수를 초과하면 사용자는 성능이 급격히 저하됩니다.
3.6.2 가상호스트 구현원리
가상호스트는 동일한 WEB 서버를 이용하여 서로 다른 도메인명을 가진 웹사이트에 서비스를 제공하는 기술이다. Apache, Tomcat 등은 구성을 통해 이 기능을 구현할 수 있습니다.
관련 HTTP 메시지 헤더: Host.
예: Host: www.baidu.com
클라이언트가 HTTP 요청을 보낼 때 Host 헤더는 클라이언트가 입력한 도메인 이름을 기록합니다. 이러한 방식으로 서버는 Host 헤더를 기반으로 클라이언트가 액세스하려는 도메인 이름을 확인할 수 있습니다.
부록: 참고 자료
"쿠키 및 세션 메커니즘 이해":
http://sumongh.javaeye.com/blog/82498
《 HTTP 프로토콜에 대한 간략한 분석":
http://203.208.39.132/search?q=cache:CdXly_88gjIJ:www.cnblogs.com/gpcuster/archive/2009/05/25/1488749.html+ http% E5%8D%8F%E8%AE%AE+web%E7%BC%93%E5%AD%98&cd=27&hl=zh-CN&ct=clnk&gl=cn&st_usg=ALhdy2-vzOcP8XTG1h7lcRr2GJrkTbH2Cg
《http 프록시_바이두 백과사전》:
http://baike.baidu.com/view/1159398.htm
《가상호스트_바이두백과사전》:
http://baike. com/view/7383.htm
《https_Baidu 백과사전》：