HTTP, HTTPS 차이 점 & 상세 설명

HTTP 프로 토 콜 버 전:
· HTTP 1.0 (짧 은 연결, 보 내기 한 번 만 들 기)
· HTTP 1.1 (긴 연결)
긴 연결, 짧 은 연결 이란 무엇 입 니까?
    짧 은 연결: 클 라 이언 트 와 서버 가 HTTP 작업 을 할 때마다 연결 을 만 듭 니 다.작업 이 끝나 면 연결 을 중단 합 니 다. 클 라 이언 트 브 라 우 저가 방문 하 는 HTML 이나 다른 유형의 웹 페이지 에 다른 웹 자원 이 포함 되 어 있 습 니 다. 이러한 웹 자원 을 만 나 지 못 하면 브 라 우 저 는 HTTP 세 션 을 다시 만 듭 니 다.    긴 연결: 긴 연결 HTTP 프로 토 콜 을 사용 하면 응답 헤더 에 이 줄 코드 를 추가 합 니 다: Connection: keep - alive.긴 연결 을 사용 한 경우 웹 페이지 가 클 라 이언 트 와 서버 를 열 어 HTTP 데 이 터 를 전송 하 는 TCP 연결 이 닫 히 지 않 고 클 라 이언 트 가 이 서버 에 다시 접근 할 때 이미 만들어 진 연결 을 계속 사용 합 니 다.keep - alive 는 영구적 인 연결 을 유지 하지 않 습 니 다. 유지 시간 이 있 습 니 다. 서로 다른 서버 소프트웨어 에서 이 시간 을 설정 할 수 있 습 니 다.
HTTP 프로 토 콜 의 주요 특징:
    1. 간단 하고 빠르다: 클 라 이언 트 가 서버 에 데 이 터 를 요청 할 때 요청 방법 과 경 로 를 전송 해 야 한다.    2. 유연성: HTTP 프로 토 콜 은 임의의 유형의 데이터 대상 을 전송 할 수 있 습 니 다.전송 중인 형식 은 Content - Type 으로 표 시 됩 니 다.    3. 연결 없 음: 연결 할 때마다 요청 하나만 처리 합 니 다.서버 가 클 라 이언 트 의 요청 을 처리 하고 클 라 이언 트 의 응답 을 받 은 후에 연결 을 끊 습 니 다.    4. 무상 태: HTTP 프로 토 콜 시 무상 태 프로 토 콜.무상 태 란 협의 가 사물 처리 에 대한 기억력 이 없다 는 것 을 가리킨다.상태 가 부족 하 다 는 것 은 후속 처리 에 앞의 정보 가 필요 하 다 면 다시 전달 해 야 한 다 는 것 을 의미한다.    5. C / S, B / S 지원
HTTP 작업 프로 세 스
    1. 먼저 클 라 이언 트 와 서버 는 연결 을 구축 해 야 합 니 다. 한 컴퓨터 의 하이퍼링크 만 있 으 면 HTTP 작업 이 시 작 됩 니 다.    2. 연결 을 만 든 후에 클 라 이언 트 는 서버 에 요청 을 보 냅 니 다. 요청 방식 의 형식 은 자원 식별 자 (URL), 버 전 번호, 뒤쪽 은 MIME 정보 입 니 다. 수식 자, 클 라 이언 트 정보 와 가능 한 내용 을 포함 합 니 다.    3. 서버 가 요청 을 받 은 후 해당 하 는 응답 정 보 를 제공 합 니 다.그 형식 은 하나의 상태 줄 로 정보의 프로 토 콜 버 전 번호, 성공 또는 실패 코드 를 포함 하고 그 다음은 MIME 정 보 는 서버 정보, 실체 정보 와 가능 한 내용 을 포함한다.    4. 클 라 이언 트 는 서버 가 되 돌아 오 는 정 보 를 브 라 우 저 를 통 해 클 라 이언 트 의 디 스 플레이 에 표시 한 다음 에 클 라 이언 트 와 서버 가 연결 을 끊 는 다.
일반적인 HTTP 상태 코드
상태 코드
속뜻
상세 한 상황
200
OK
서버 에서 요청 을 성공 적 으로 처리 하 였 습 니 다.
301
영구 이동
요청 한 웹 페이지 가 새 위치 로 영구적 으로 이동 하 였 습 니 다.서버 가 응답 을 되 돌 릴 때 요청 자 를 자동 으로 새 위치 로 이동 합 니 다.
302
임시 이동
서버 는 현재 서로 다른 위치 에 있 는 웹 페이지 에서 요청 에 응 하지만 요청 자 는 기 존 위 치 를 계속 사용 하여 향후 요청 을 진행 해 야 합 니 다.
307
임시 방향 변경
서버 는 현재 서로 다른 위치 에 있 는 웹 페이지 에서 요청 에 응 하지만 요청 자 는 기 존 위 치 를 계속 사용 하여 향후 요청 을 진행 해 야 합 니 다.
400
오류 요청
서버 가 요청 한 문법 을 이해 하지 못 합 니 다.
403
금지 하 다.
서버 요청 거부
404
찾 을 수 없 음
서버 에서 요청 한 웹 페이지 를 찾 을 수 없습니다.
500
서버 내부 오류
서버 에 오류 가 발생 하여 요청 을 완료 할 수 없습니다.
HTTP 와 HTTPS 의 차이 점:
구별:    1. HTTPS 에 필요 한 ca 신청 증 서 는 일반적으로 무료 인증서 가 적 고 일정한 비용 이 필요 합 니 다.        확장: ca (certification authority) 는 공개 키 인 프 라 pki (Public key infrastructure) 를 바탕 으로 디지털 인증 서 를 생 성하 고 확정 한 제3자 신뢰 기구 로 주로 신분증 발급 을 하고 디자이너 가 지정 한 전략 에 따른다.전자 인증서 의 정상 적 인 사용 을 관리 하 다.    2. HTTP 하이퍼텍스트 전송 은 명문 전송 이 고 HTTPS 는 SSL 암호 화 전송 프로 토 콜 을 가진다.    3. HTTP 는 80 포트 를 사용 하고 HTTPS 는 443 포트 를 사용한다.    4. HTTP 연결 이 단순 무 상태 입 니 다.HTTPS 프로 토 콜 은 SSL + HTTP 프로 토 콜 이 구축 한 암호 화 전송, 인증 이 가능 한 네트워크 프로 토 콜 로 HTTP 보다 안전 합 니 다.        SSL: (Secure Sockets Layer 안전장치 연결 층) 과 그 계승자 전송 층 안전 (Transport Later Security, TLS) 은 네트워크 통신 에 안전 과 데이터 완전 성 을 제공 하 는 안전 프로 토 콜 입 니 다.TLS 와 SSL 은 전송 층 에서 네트워크 연결 을 암호 화 합 니 다.
HTTP 의 단점:

통신 내용 은 명문 이 고 암호 화 되 지 않 으 며 내용 은 감청 될 수 있다. 감청 은 인터넷 통신 에서 발생 할 수 있 는 각 부분

통신 쌍방 이 인증 을 하지 않 아 신분 을 위장 하 는 상황 이 발생 할 수 있 으 므 로 모든 사람 이 서버 에 요청 할 수 있다.    클 라 이언 트 에 게 서버 가 실제 서버 인지 확인 할 방법 이 없고 서버 에 있어 서 자신 이 돌아 온 메시지 가 클 라 이언 트 에 의 해 진정 으로 받 아들 여 졌 는 지 확인 할 수 없습니다.     따라서 서버 의 전체 수신 단점 은 DOS 공격 을 깨 우 는 데 사용 되 기 쉽다.    클 라 이언 트 의 경우 클 라 이언 트 는 서버 통신 전에 서버 의 신분 을 확인 해 야 한다. 이 신분 은 인증서 이 고 이 인증 서 는 신뢰 할 수 있 는 제3자 가 발급 하 며 클 라 이언 트 는 신분 을 확인 한 후에 야 통신 을 한다.

받 은 메시지 의 완전 성 은 확실 하지 않 아 중간 에 바 뀔 수 있다. 서버 는 요청 을 받 은 후에 응답 합 니 다.그러나 서버 와 클 라 이언 트 는 메시지 가 도중에 전송 되 는 데 문제 가 있 는 지 알 수 없습니다.전송 중 다른 공격 자 에 의 해 조작 되 어 메시지 의 완전 성 이 파 괴 될 가능성 이 크다.

HTTPS 에 대하 여

HTTPS     HTTP      ， HTTP         ，HTTPS HTTP       ：
    ·     
    ·     
    ·      

    SSL 은 어떻게 HTTP 와 협조 하여 안전 통신 에 도달 합 니까?        우선 우리 가 알 아야 할 것 은 HTTPS 가 새로운 프로 토 콜 이 아니 라 HTTP 의 통신 인터페이스 부분 은 SSL 프로 토 콜 로 이 루어 졌 다 는 것 이다. 위의 그림 에서 알 수 있 듯 이 SSL 은 HTTP 프로 토 콜 에 독립 되 어 있 고 SMTP 와 같은 다른 프로 토 콜 의 암호 화 에 도 사용 할 수 있다.
일반적인 암호 화 방식
    · 공유 키 암호 화 (대칭 키)    말 그대로 클 라 이언 트 와 서버 는 똑 같은 열 쇠 를 가지 고 있 습 니 다. 메시지 의 암호 화 와 복호화 에 동의 하 는 열 쇠 를 사용 하고 키 도 통신 과정 에서 상대방 에 게 보 내야 상대방 이 이 키 를 사용 하여 복호화 할 수 있 습 니 다.그래서 전송 과정 에서 이 열 쇠 를 공격 자가 가 져 오 면 메시지 암호 화 도 의 미 를 잃 게 된다.
    · 공개 키 암호 화    공유 키 는 이 열 쇠 를 상대방 에 게 안전하게 보 낼 수 있 도록 하 는 것 이 큰 문제 입 니 다.공개 키 는 이 문 제 를 잘 해결 했다.    공개 키 암호 화 에 사용 되 는 비대 칭 키 입 니 다.하 나 는 공유 키 이 고 하 나 는 개인 키 입 니 다.공유 키 는 통신 쌍방 에 공개 되 며 누구나 얻 을 수 있 으 며 개인 적 인 것 은 공개 되 지 않 습 니 다.발송 자 는 이 공유 키 를 사용 하여 메 시 지 를 암호 화하 고 수신 자 는 개인 키 를 사용 하여 복호화 합 니 다.
HTTPS 는 혼합 암호 화 메커니즘 을 채택 한다
    공유 키 의 메커니즘 이 상대 적 으로 복잡 하기 때문에 처리 속도 가 상대 적 으로 느리다.HTTPS 는 우선 공유 키 를 통 해 암호 화 전송 을 합 니 다.공유 키 가 상대방 에 게 안전하게 전 송 된 후에 쌍방 은 공유 키 방식 으로 메 시 지 를 암호 화하 여 효율 을 높 인 다.
HTTPS 의 핸드 폰 시스템:
    1. 클 라 이언 트 (브 라 우 저) 가 HTTP 요청 을 일 으 켜 서버 에 연결 을 요청 하고 지원 하 는 암호 화 통신 프로 토 콜 (버 전) 을 보 내 며 무 작위 수 를 생 성하 여 '대화 키' 를 생 성 합 니 다.    2. 서버 에서 암호 화 통신 프로 토 콜 (버 전과) 을 확인 하고 무 작위 수 를 생 성하 여 '대화 키' 를 생 성하 고 CA 에서 발급 한 디지털 인증 서 를 클 라 이언 트 에 함께 보 냅 니 다.    3. 클 라 이언 트 가 디지털 인증 서 를 받 은 후에 내 장 된 '신뢰 받 는 루트 인증서 발급 기구' 를 검사 하고 디지털 인증 서 를 풀 수 있 는 숟가락 이 존재 하 는 지 확인 합 니 다.    4. 디지털 인증 서 를 풀 수 있 는 수저 가 존재 한다 면 이 를 사용 하여 디지털 인증 서 를 풀 고 정확 한 서버 수 저 를 받 으 며 랜 덤 수 를 다시 생 성하 여 서버 수저 암호 화 에 사용 하고 서버 에 보 냅 니 다.    5. 이 때 로 컬 과 서버 는 세 개의 무 작위 수 를 동시에 암호 화하 고 약 정 된 암호 화 방법 에 따라 각각 이번 세 션 에서 사용 하 는 같은 '세 션 키' 를 생 성 합 니 다.    6. 여기까지 인증 단계 가 완료 되 었 습 니 다. 데이터 전송 은 비대 칭 암호 화 에서 대칭 암호 화 (성능 을 고려 하여) 로 바 뀌 었 습 니 다. 그 다음 에 모든 데이터 전송 은 HTTP 프로 토 콜 로 전송 되 었 습 니 다. '세 션 키' 로 내용 을 암호 화 했 을 뿐 입 니 다.
도해

HTTP 와 HTTPS 를 선택 하 는 방법
    SSL 은 통신 의 효율 을 떨 어 뜨 릴 수 있다.        ·통신 속도 감소: HTTPS 는 TCP 연결, 전송 요청, 응답 외 에 SSL 통신 이 필요 합 니 다.전체적인 통신 정 보 량 이 증가 하 다.        ·암호 화 과정 은 자원 을 소모 합 니 다. 모든 메 시 지 는 암호 화 와 복호화 의 연산 처 리 를 해 야 합 니 다.HTTP 보다 서버 자원 이 더 많이 소 모 됩 니 다.        ·인증서 비용: HTTPS 를 통 해 통신 하려 면 인증 기관 에 인증 서 를 구 매해 야 합 니 다.    위의 세 가 지 를 바탕 으로 우리 가 재 통신 에서 전송 하 는 비 민감 한 정 보 는 HTTP 프로 토 콜 을 많이 선택 할 것 이다.통신 과정 에서 개인 프라이버시 나 다른 안전 정보 가 관련 될 경우 HTTPS 를 선택한다.물론 방 문 량 도 고려 하 는 요소 중 하나 로 방 문 량 이 많 으 면 메시지 마다 암호 화 해 밀 을 하 는 것 도 서버 에 큰 부담 을 줄 수 있다.