HTTP 및 HTTPS 프로토콜

HTTP 프로토콜

통신 프로토콜 : 데이터 교환의 형태로 서버와 클라이언트

HTTP 작동 : HTTP 프로토콜은 클라이언트에서 작동 -에 서버 아키텍처. HTTP 서버의 모든 웹 서버에 URL 요청을 통해 전송되는 HTTP 클라이언트와 같은 브라우저는 수신 요청에 따라 웹 서버는 클라이언트에 대한 응답 정보를 전송

포 포인츠 노트

HTTP 데이터 객체의 모든 유형의 전송을 할 수 있습니다. 그것은 전송의 유형은 콘텐츠 형식으로 표시되고
HTTP는 비 연결이다 : 제한 없음을 의미없는 것은 연결 당 하나의 요청을 첨부되어 있습니다. 서버는 클라이언트 요청을 처리하고 고객의 반응, 즉, 분리를 수신 한 후. 이러한 방식은 전송 시간을 절약 할 수 있습니다.
HTTP는 독립적 인 미디어입니다 : 이것은 한 클라이언트와 서버가 HTTP를 통해 전송 될 수있는 데이터의 모든 유형의 데이터 내용을 처리하는 방법을 알고 있다는 것을 의미한다. 클라이언트와 서버는 적절한 MIME 타입의 콘텐츠 형식을 지정합니다.
HTTP 프로토콜 비 저장 프로토콜 : HTTP는 무 상태입니다. 없음 상태는 트랜잭션 처리 및 메모리에 대한 프로토콜입니다. 상태의 부족 정보 앞에 필요한 후속 처리는이 재전송되어야 함을 의미하는 경우 상승 각 연결 전송되는 데이터의 양을 초래할 수있다. 한편,시는 빠른 서버에 응답하여 이전 정보를 요구하지 않습니다.

는 HTTP URL

HTTP에서는 데이터를 송신하고, 연결을 설정하는 균일 한 자원 식별자 (유니폼 리소스 ldentifiers, URI)를 사용한다. 대한 URL은 URI의 특별한 유형은, 충분한 정보 URL을 찾기위한 자원이 포함되어있다 범용의 약자, 중국라는 균일 한 리소스 로케이터 인터넷에서 주소 자원을 식별하는 데 사용됩니다. 예를 들어, 다음 일반 URL의 구성의 각 부분에 따라 다음 URL에서 :

http:/www.aspxfans.com:8080/news/index.asp?boardlD=5&ID=24618&page=1#name

위의 URL에서 볼 수 있듯이, 전체 URL 내용은 다음과 같습니다

프로토콜 : URL의 부분에 대한 프로토콜 http:HTTP 프로토콜을 사용하여 웹 페이지를 나타냅니다. 이 예에서 사용 등 HTTP, FTP와 같은 인터넷 프로토콜, 다양한에서 사용할 수 있음은 HTTP 프로토콜입니다. 에서 http의 뒷면 //구분
도메인 이름 부분 : URL의 도메인 이름 부분입니다 www.aspxfans.com. URL은, 또는 당신은 도메인 이름과 IP 주소를 사용할 수 있습니다
포트 섹션 : 도메인 이름 다음은 포트, 도메인 이름과 포트 사이에 사용하는 :구분자로. 이 포트의 일부를 생략하면 포트, URL의 필수 일부가 아닌, 기본 포트
가상 디렉토리 섹션 : 도메인 이름이 첫 번째 후 /마지막에 시작 /날짜, 가상 디렉토리의 일부입니다. 가상 디렉토리는 URL의 필요한 부분이 아닙니다. 이 경우 가상 디렉토리입니다/news/
이름 부분을 파일 : 마지막 이름 다음에서 /시작 ?날짜, 파일 이름의 일부가 아닌 경우 ?, 그 도메인 후 마지막 하나입니다 /로 시작 #하지 않을 경우, 날짜, 파일 부분 ?, 및 #도메인 후 마지막에서 다음 /시작 끝으로, 파일 이름의 일부입니다. 이 예제 파일 이름에서 index.asp. 파일 이름의 일부는, 당신은이 부분을 생략하면, 기본 파일 이름이 URL의 필요한 일부가 아닙니다
앵커 부분은 :부터 #끝까지 시작, 그것은 앵커의 일부입니다. 이 실시 예에서, 앵커 부이다 name. URL의 앵커 부분은 필요한 부분 아닙니다
매개 변수 섹션에서 ?받는 시작 #도 액세스 케이블 섹션에서 쿼리 부분으로 알려진까지 부분 사이의 논쟁의 일부. 이 예제의 매개 변수입니다 boardlD=5&ID=24618&page=1. 파라미터는 복수의 파라미터, 상기 파라미터의 파라미터 있도록 &구분자로한다.

HTTP의 之 요청

클라이언트는 서버의 HTTP 요청 메시지에 요청에는 다음과 같은 구성 요소가 포함 보냅니다

헤더 : 자주 요청 헤더는 요청에 대한 주요 설명의 일부에 저장되고, 요청 헤더를했다. 따라서 서버는 클라이언트 정보를 얻을 수있다.

일반적인 요청 헤더 :

accept：浏览器通过这个头告诉服务器，它所支持的数据类型
Accept-Charset：浏览器通过这个头告诉服务器，它支持哪种字符集
Accept-Encoding：浏览器通过这个头告诉服务器，支持的压缩格式
Accept-Language：浏览器通过这个头告诉服务器，它的语言环境
Host：浏览器通过这个头告诉服务器，想访问哪台主机
If-Modified-since：浏览器通过这个头告诉服务器，缓存数据的时间
Referer：浏览器通过这个头告诉服务器，客户机是哪个页面来的防盗链
Connection：浏览器通过这个头告诉服务器，请求完后是断开链接还是保持链接   ★★★
X-Requested-with：XMLHttpRequest代表通过ajax方式进行访问
User-Agent：请求载体的身份标识    ★★★

메시지 본문 : 요청 본문은 종종라고는 정보를 서버로 전송 / 데이터를 전송할 요청 본문에 저장됩니다

HTTP의 之 요청

서버가 응답 메시지에는 다음과 같은 구성 요소가 포함 클라이언트에 HTTP 응답을 반환 :

상태 코드 : "명확한"언어는이 요청의 결과를 처리하는 클라이언트를 알려줍니다. HTTP 응답 상태 코드는 다섯 개 부분으로 구성된다 :
- 1XX는 : 보통 요구를 수신 한 클라이언트에게 처리 중입니다
- 가 2xx : 성공적인 치료는 일반적으로 요청이 수신되었음을 나타냅니다, 당신이 원하는 것을 이해하고, 요청이 받아 들여졌다 및 기타 정보가 처리 된
- 3xx의 : 다른 리디렉션. 그런 다음 클라이언트가 전체 프로세스를 완료하는 요청을 시작 할 수 있습니다
- 4XX는 : 클라이언트가 존재하지 않는 자원을 요청하는 등의 에러 처리는, 클라이언트가 등의 액세스를 금지 할 권한이없는 대신, 클라이언트의 책임을 취
- 5XX : 오류 처리는 서버와 서비스 측의 책임은, 예외, 라우팅 오류, HTTP 버전이 지원하지 않는 등 발생, 발생

응답 헤더 : 세부 정보 응답을 보여줍니다. 일반적인 응답 헤더는이

Location：服务器通过这个头，来告诉浏览器跳到哪里
Server：服务器通过这个头，告诉浏览器服务器的型号
Content-Encoding：服务器通过这个头，告诉浏览器，数据的压缩格式
Content-Length：服务器通过这个头，告诉浏览器回送数据的长度
Content-Language：服务器通过这个头，告诉浏览器语言环境
Content-Type：服务器通过这个头，告诉浏览器回送数据的类型    ★★★
Refresh：服务器通过这个头，告诉浏览器定时刷新
Content-Disposition：服务器通过这个头，告诉浏览器以下载方式打数据
Transfer-Encoding：服务器通过这个头，告诉浏览器数据是以分块方式回送的
Expires：-1 控制浏览器不要缓存
Cache-Control：no-cache 
Pragma：no-cache

본문에 응답하여 : 상기 요청에 따라 클라이언트에 의해 지정된 정보와 클라이언트로 지정된 데이터를 전송

HTTPS 프로토콜

개념 : HTTPS (보안 하이퍼 텍스트 전송 프로토콜) 보안 하이퍼 텍스트 전송 프로토콜, HTTPS SSL 암호화 층은 HTTP를 기반으로하고, 암호화 된 데이터는 HTTP 프로토콜의 보안 버전입니다.

암호화는 HTTPS를 사용

SSL 암호화

"공유 키"라고 고용 SSL 암호화 기술은 또한 "대칭 키 암호화"라고,이 암호화 방법은 클라이언트가 서버에 메시지를 보내 예를 들어, 그런 알려진 알고리즘을 사용하여 첫 번째 클라이언트 정보는 예컨대 MD5 또는 Base64로 암호화로 암호화되는 경우, 수신단은 상기 암호화 된 정보는 키, 중간 키가 전달된다 (암호화 및 복호화가 동일) 사용해야 복호화 송신 중간 키이며 암호화. 이러한 접근 방식은 키를 해독하고, 정보를 파괴 할 수 있으며, 안전 보이지만, 지원 또는 정보, 여전히 잠재적으로 위험한 번 탭이 있습니다. 따라서, 보안 위험이 방법을 "키 암호화를 공유".

비대칭 암호화 비밀 키

은 "비대칭 암호화"를 사용하는 경우 두 개의 잠금은 "개인 키"는 "공개 키"라는 일이 있습니다 비대칭 암호화 암호화 방법을 사용하는 경우, 서버는 주어진 자신의 첫 번째에 따라 클라이언트를 알려줍니다 공개 키 암호화, 공개 키 암호화 한 후 클라이언트에 따라, 서버 따라서, 전송을 수행하고하지 않을 그렇게의 혜택을 해독하기 위해 키를 자신의 개인 키를됩니다 사용, 암호를 해독 한 후 정보를 수신하고, 피 납치의 위험. 공개 키가 도청을 얻을 수있다하더라도, 그것은 때문에 평가 이산 대수의 해독 과정을 해독하기 어려운이 쉽게 할 수 없습니다. 다음 비대칭 암호화 회로도 :

그러나 비대칭 비밀 키 암호화 기술은 다음과 같은 단점이 있습니다 :

제이다 : 수신단 시간, 송신 측의 비밀 키를 개시 전송되도록하는 방법을 사전에 송신 측이없이 수신 된 전송이 개재되는 것을 보장한다. 만큼 키가 전송 될 때, 인질로 잡혀 위험이있을 수 있습니다.
두번째는 비대칭 암호화 방법은 상대적으로 비효율적이고,이 통신 속도 및 효율성에 일정한 영향을 미칠 통신시 취급이보다 복잡

HTTPS 인증 메커니즘

위, 우리는 공개 키의 존재가 납치 될 가능성이 첫 번째있는 비대칭 암호화의 단점에 대해 이야기, 공개 키는 클라이언트가 서버의 공개 키가 출시 수신 보장 할 수 없습니다. 이 때, 공개 키 인증 메커니즘이 발생한다. 인증 기관은 타사 클라이언트와 서버가 신뢰할 수있는 것입니다. DETAILED 통신 처리 인증은 다음과 같이 :

1 : 서버 개발자는 공개 키 인증 기관에 적용 할 수있는 공개 키, 신청자의 신원을 인식하는 인증 기관 승인 후, 디지털을 할 것입니다 응용 프로그램 개발자의 공개 키를 전달하는 공개 키는 함께 결합, 내부에 인증서와 키를 서명 한 서명 한 후 지정
2：服务器将这份数字证书发送给客户端，因为客户端也认可证书机构，客户端可以通过数字证书中的数字签名来验证公钥的真伪，来确保服务器传过来的公开密钥是真实的。一般情况下，证书的数字签名是很难被伪造的，这取决于认证机构的公信力。一旦确认信息无误之后，客户端就会通过公钥对报文进行加密发送，服务器接收到以后用自己的私钥进行解密。