REST / HTTP / HTTPS 프로 토 콜 기반
5105 단어 협의
1.1 정의: HTTP 프로 토 콜 은 컴퓨터 통신망 에서 두 컴퓨터 간 에 통신 을 할 때 반드시 공동으로 지 켜 야 하 는 규정 이나 규칙 을 말 합 니 다. 하이퍼텍스트 전송 프로 토 콜 (HTTP) 은 하이퍼텍스트 태그 언어 (HTML) 문 서 를 웹 서버 에서 클 라 이언 트 로 전송 하 는 브 라 우 저 를 허용 하 는 통신 프로 토 콜 입 니 다.현재 우리 가 사용 하고 있 는 것 은 HTTP / 1.1 버 전이 다.
브 라 우 저 를 열 고 주소 표시 줄 에 URL 을 입력 한 후에 우 리 는 웹 페이지 를 보 았 다.원 리 는 어 떻 습 니까?실제로 우리 가 URL 을 입력 한 후, 우리 의 브 라 우 저 는 웹 서버 에 Request 를 보 냈 습 니 다. 웹 서버 는 Request 를 받 은 후에 처리 하고, 상응하는 Response 를 생 성하 여 브 라 우 저 에 보 내 고, 브 라 우 저 는 Response 중의 HTML 을 분석 합 니 다. 이렇게 해서 우 리 는 웹 페이지 를 볼 수 있 습 니 다.우리 의 Request 는 프 록 시 서버 를 거 쳐 웹 서버 에 도 착 했 을 수도 있 습 니 다.
1.2 URL 형식 분석: URL (Uniform Resource Locator) 주 소 는 네트워크 의 자원 을 설명 하 는 데 사 용 됩 니 다.:
schema://host[:port#]/path/.../[?query-string][#anchor]
scheme 는 저층 에서 사용 할 프로 토 콜 (예: http, https, ftp) host HTTP 서버 의 IP 주소 나 도 메 인 이름 port \ # HTTP 서버 의 기본 포트 는 80 이 므 로 생략 할 수 있 습 니 다.다른 포트 를 사용 하려 면, 예 를 들 어http://www.baidu.com:8080/ path 자원 접근 경로 query - string http 서버 에 보 낸 데이터 anchor - 닻
1.3 HTTP 메시지 구조 체
Request 메 시 지 는 위의 그림 과 같이 세 부분 으로 나 뉜 다. 첫 번 째 부분: Request line, Method 는 요청 방법 을 나타 낸다. 예 를 들 어 "POST", "GET" 두 번 째 부분: Request header 세 번 째 부분: body.
Response 메시지 의 구조 체 는 위의 그림 과 같다. 첫 번 째 부분: Status line, 상태 줄, HTTP 프로 토 콜 버 전 번호, 상태 코드, 상태 메시지 세 부분 으로 두 번 째 부분 을 구성한다. Response header 세 번 째 부분: bodyHTTP / 1.1 에서 5 가지 상태 코드 를 정 의 했 습 니 다. 1XX 알림 정보 - 요청 이 성공 적 으로 받 아들 여 졌 음 을 의미 합 니 다. 2XX 를 계속 처리 하 는 데 성 공 했 음 을 의미 합 니 다. - 요청 이 성공 적 으로 받 아들 여 졌 음 을 의미 합 니 다. 이해 합 니 다.3XX 재 설정 수락 - 요청 을 완료 하려 면 4XX 클 라 이언 트 오 류 를 좀 더 처리 해 야 합 니 다. - 문법 오류 가 있 거나 5XX 서버 쪽 오류 가 발생 할 수 없습니다. - 서버 가 합 법 적 인 요청 을 수행 하지 못 했 습 니 다.
2. TCP 프로 토 콜 2.1 연결 tcp 프로 토 콜 을 구축 하고 세 개의 메시지 세그먼트 를 통 해 연결 을 완성 하 며 세 번 의 악수 라 고 합 니 다.
TCP 연결 을 닫 으 려 면 네 번 의 악수 가 필요 합 니 다. 그림: 1. TCP 클 라 이언 트 가 FIN 메 시 지 를 보 냅 니 다. 2. TCP 서버 가 ACK 응답 메 시 지 를 보 내 고 FIN 메 시 지 를 보 냅 니 다. 3. TCP 클 라 이언 트 가 ACK 메 시 지 를 받 은 후 ACK 응답 서버 측의 FIN 메 시 지 를 보 냅 니 다. 4. TCP 서버 가 ACK 를 받 은 후 TCP 연결 을 닫 습 니 다.[문제 1] 왜 연결 할 때 악 수 를 세 번 하고 닫 을 때 악 수 를 네 번 해요?답: 서버 에서 클 라 이언 트 측의 SYN 연결 요청 메 시 지 를 받 으 면 SYN + ACK 메 시 지 를 직접 보 낼 수 있 기 때 문 입 니 다.그 중에서 도 ACK 메 시 지 는 응답 용 이 었 고 SYN 메 시 지 는 동기 화 용 이 었 다.그러나 연결 을 닫 을 때 서버 측 에서 FIN 메 시 지 를 받 았 을 때 SOCKET 을 바로 닫 지 않 을 가능성 이 높 기 때문에 먼저 ACK 메시지 에 답 해 클 라 이언 트 측 에 "당신 이 보 낸 FIN 메 시 지 를 받 았 습 니 다" 라 고 알려 야 합 니 다.내 서버 의 모든 메 시 지 를 다 보 낼 때 까지 기 다 려 야 나 는 FIN 메 시 지 를 보 낼 수 있 기 때문에 함께 보 낼 수 없다.그래서 네 걸음 악수 가 필요 해 요.
3 SSL 프로 토 콜: 프로 토 콜 은 웹 브 라 우 저 와 웹 서버 간 에 정 보 를 안전하게 교환 하 는 프로 토 콜 로 두 가지 기본 적 인 안전 서 비 스 를 제공 합 니 다. 감별 과 비밀 입 니 다.3.1 세 가지 특징: ① 비밀 유지: 악수 프로 토 콜 에서 세 션 키 를 정의 한 후에 모든 메시지 가 암호 화 됩 니 다.② 감별: 선택 가능 한 클 라 이언 트 인증 과 강제 서버 엔 드 인증.③ 완전 성: 전 송 된 메 시 지 는 메시지 의 완전 성 검사 (MAC 사용) 를 포함한다.
3.2 SSL 구조의 SSL 은 응용 층 과 TCP 층 사이 에 있다.응용 층 데 이 터 는 전송 층 에 직접 전달 되 지 않 고 SSL 층 에 전달 되 며 SSL 층 은 응용 층 에서 받 은 데 이 터 를 암호 화하 고 자신의 SSL 헤드 를 추가 합 니 다.
3.2 SSL 악수 연결 과정 1. client 송신 Client Hello, 지정 버 전, 난수 (RN), 지원 하 는 모든 암호 세트 (CipherSuites) 2. server 응답 Server Hello, 지정 버 전, RN, 선택 CipherSuites, 세 션 ID (Session ID) 3. server 송신 Certificate 4. Server 송신 Server HelloDone 5. Client 송신 Client KeyExchange,server 와 session key 6. Client 를 교환 하여 Change Cipherspec 를 보 내 는 데 사 용 됩 니 다. 서버 가 지금부터 보 내 는 메 시 지 는 암호 화 된 7. Client 에서 Finishd 를 보 냅 니 다. 앞의 모든 악수 메 시 지 를 포함 한 hash 는 server 가 악수 과정 이 제3자 에 의 해 변경 되 었 는 지 검증 할 수 있 습 니 다. Server 에서 Change Cipherspec 를 보 냅 니 다.클 라 이언 트 에 게 지금부터 보 내 는 메 시 지 는 암호 화 된 9. Server 에서 Finishd 를 보 냅 니 다. 앞의 모든 악수 메 시 지 를 포함 한 hash 는 클 라 이언 트 로 하여 금 악수 과정 이 제3자 에 의 해 변경 되 었 는 지 검증 하고 자신 이 Certificate 키 의 소유자 임 을 증명 할 수 있 습 니 다. 즉, 자신의 신분 을 증명 하 는 것 입 니 다.
좋은 웹페이지 즐겨찾기
