HTTP 그런 거.

머리말
오 랜 만 에 인터넷 이라는 부분 을 건 드 려 서 어색 하 다 고 느 꼈 는데, 최근 '도해 HTTP' 를 사서 며칠 만 에 다 봤 다.통속 적 이어서 읽 기 에 매우 빠르다.읽 은 후에 비교적 중요 한 HTTP 지식 을 정리 하여 기록 하 세 요.본문 은 많은 부분 을 생략 하 였 는데, 결코 그것 이 중요 하지 않 기 때 문 이 아니다.그 중에서 주로 두 가지 가 있 는데 하 나 는 기본 적 인 기억 성 지식 을 생략 했다. 예 를 들 어 메시지 의 첫 번 째 필드 의 해석 등 이다.둘째, HTTPS 가 어떻게 여러 측면 에서 안전성 을 확보 하 는 지 등 깊이 있 는 설명 을 생략 했다. 이런 설명 을 하려 면 많은 지면 을 써 야 하고 많은 그림 을 그 려 서 도 해 를 해 야 하기 때문이다.시간 이 제한 되 어 비교적 간단하게 썼 다.언제 깊이 복습 하고 싶 으 면 다시 책 을 넘 기 면 됩 니까?다시 한 번 '도해 HTTP' 를 추천 합 니 다. 보고 나 면 HTTP 에 대해 많이 알 지 못 할 것 입 니 다. 깊이 공부 하고 싶 으 면 'HTTP 권위 지침' 을 사 겠 습 니 다. 이 책 은 저도 샀 습 니 다. 덩치 가 너무 커서 잠시 방치 하 겠 습 니 다.
HTTP 가 뭐 예요?
HTTP (HyperText Transfer Protocol, 하이퍼텍스트 전송 프로 토 콜).클 라 이언 트 와 서버 간 통신 에 사용 되 는 프로 토 콜 입 니 다.합의 란 어떤 목적 을 달성 하기 위 한 약속 이다.우 리 는 인터넷 과 관련 된 각종 협의 족 을 TCP / IP 라 고 부른다.우리 먼저 협의 족 에 대해 알 아 보 자.
- TCP / IP 의 계층 적 관리 -
TCP / IP 프로 토 콜 족 은 차원 에 따라 4 층 으로 나 뉜 다. 응용 층, 전송 층, 네트워크 층, 데이터 링크 층 이다.협의 족 은 왜 층 을 나 누 어야 합 니까?코드 의 디 결합 사상 과 유사 하 다 고 할 수 있다.(넓 은 의미 에서 볼 때 인류 사회 생활 에서 의 사회 분업 행위 도 결합 을 해제 하고 효율 을 향상 시 키 는 등 역할 을 한다.) * * 응용 층: 응용 층 은 사용자 에 게 응용 서 비 스 를 제공 할 때 통신 하 는 활동 을 결정 한다.FTP (File Transfer Protocol, 파일 전송 프로 토 콜) 와 DNS (Domain Name System, 도 메 인 네 임 시스템), HTTP 프로 토 콜 은 모두 응용 계층 프로 토 콜 에 속 합 니 다. * *전송 층: 전송 층 은 네트워크 연결 에 있 는 두 컴퓨터 간 의 데이터 전송 을 제공 합 니 다.전송 층 에는 TCP (Transmission Control Protocol, 전송 제어 프로 토 콜) 와 UDP (User Data Protocol, 사용자 데이터 보고 프로 토 콜) 두 가지 성질 이 다른 프로 토 콜 이 있 습 니 다. * * *네트워크 계층: 패 킷 은 네트워크 에서 한 대의 컴퓨터 에서 목적 컴퓨터 에 도달 하려 면 여러 대의 컴퓨터 나 네트워크 장 치 를 거 쳐 야 합 니 다.네트워크 계층 의 역할 은 전송 노선 을 선택 하 는 것 입 니 다. * *데이터 링크 층: 네트워크 를 연결 하 는 하드웨어 부분 을 처리 합 니 다.
* * DNS: * * 도 메 인 네 임 분석 시스템 은 말 그대로 도 메 인 네 임 에서 IP 주소 사이 의 분석 서 비 스 를 제공 합 니 다.사람 은 의미 있 는 도 메 인 네 임 을 사용 하여 특정한 컴퓨터 를 방문 하 는 습관 이 있 지만 컴퓨터 는 디지털 형식의 IP 주 소 를 처리 하 는 데 더욱 능 하기 때문에 이들 사이 에 전환 작업 이 있어 야 한다. 여 기 는 도 메 인 네 임 시스템 DNS 가 하 는 일이 다.TCP: TCP 는 전송 층 에 위치 하여 신뢰 할 수 있 는 바이트 스 트림 서 비 스 를 제공 합 니 다. '바이트 스 트림 서비스' 는 전송 이 편리 하고 큰 데 이 터 를 여러 개의 패 킷 으로 나 누 어 관리 하 는 것 을 말 합 니 다.'믿 을 만 한' 이란 데이터 가 최종 적 으로 상대방 에 게 전달 되 는 지 확인 하기 위해 유명한 세 번 의 악수 전략 을 사용 한 것 을 말한다.
우 리 는 프로 토 콜 족의 지식 을 알 게 된 후에 이제 일반적인 통신 과정 을 정리 합 니 다. 먼저 클 라 이언 트 가 서버 의 특정한 자원 을 방문 하고 싶 습 니 다. 예 를 들 어 http://hackr.jp/xss/Web 서버 에 방문 하려 면 컴퓨터 가 잘 처리 하 는 것 은 IP 주소 이기 때문에 응용 층 에서 DNS 서 비 스 를 시작 하고 도 메 인 이름 hackr.jp 을 IP 주소 20x.189.105.112 로 전환 해 야 합 니 다.이 어 HTTP 프로 토 콜 을 근절 하고 클 라 이언 트 의 요구 에 따라 HTTP 요청 메 시 지 를 생 성 합 니 다.그리고 TCP 연결 을 구축 하여 요청 메 시 지 를 메시지 세그먼트 로 나 누 어 각각 신뢰 할 수 있 게 전송 합 니 다.서버 로 전송 되 는 과정 에서 여러 대의 컴퓨터 를 거 쳐 중간 에 돌리 면서 서버 까지 전송 합 니 다. * *서버 에 도착 하면 클 라 이언 트 와 데 이 터 를 보 낼 때 역 주 행 동작 을 합 니 다. * *
HTTP 메시지 의 구조
HTTP 의 메시지 구조 에 대해 서 는 대략적인 구 조 를 잘 알 고 원리 적 인 것 만 이해 하면 된다.일부 자구 의 해석 은 모두 기억 이 필요 한 기초 지식 으로 인터넷 에서 찾 을 수 있 는 자료 가 많 으 니 여기 서 군말 하지 않 겠 다.필요 할 때 인터넷 으로 찾 아 보 거나 책 을 뒤 져 보면 된다.
HTTP 메시지 의 대체 구 조 를 파악 해 야 하 는 것 외 에 도 몇 가지 흔 한 요청 방법 GET/POST/HEAD/PUT/DELETE 등 을 구분 해 야 한다.응답 메시지 에서 일부 상태 코드 가 대표 하 는 의미 (2xx: 성공, 3xx: 재 향, 4xx: 클 라 이언 트 문제, 5xx: 서버 쪽 문제) 도 잘 알 아야 합 니 다.또한 메시지 의 첫 번 째 필드 의 의 미 를 잘 알 아야 합 니 다. 어떤 것 은 중요 합 니 다. 이 HTTP 요청 의 기능 성 을 결정 합 니 다.
몇 가지 비교적 중요 한 문제
- HTTP 는 상 태 를 저장 하지 않 는 프로 토 콜 입 니 다. HTTP 프로 토 콜 은 '무상 태 프로 토 콜' 입 니 다. 상 태 를 저장 하지 않 는 프로 토 콜 입 니 다. 기억 이 없습니다. 요청 과 응답 할 때마다 정 보 를 저장 하지 않 습 니 다.그러나 실제 응용 에서 사용자 상 태 를 저장 하 는 것 은 실제 존재 하 는 수요 이기 때문에 우 리 는 Cookie 기술 을 도입 하여 사용자 정 보 를 저장 하고 상 태 를 유지 하 는 데 사용 했다.Cookie 서버 에서 보 낸 응답 메시지 에 있 는 Set-Cookie 라 는 첫 번 째 필드 정보 에 따라 클 라 이언 트 에 게 저장 Cookie 을 알 립 니 다.다음 클 라 이언 트 가 이 서버 에 요청 을 보 낼 때 클 라 이언 트 는 자동 으로 요청 메시지 에 Cookie 값 을 추가 한 후에 보 냅 니 다.서버 는 클 라 이언 트 가 보 낸 Cookie 값 을 발견 하고 어떤 클 라 이언 트 에서 보 낸 연결 요청 인지 확인 한 다음 에 서버 의 기록 을 비교 하여 상태 정 보 를 얻 습 니 다.
- * * 지속 적 인 연결, 통 신 량 절약 - HTTP 초기 버 전에 서 HTTP 통신 을 할 때마다 TCP 연결 을 끊 어야 합 니 다.이것 은 텍스트 전송 을 위주 로 하 던 해 에 문제 가 없 었 다.하지만 지금 은 자원 유형 이 갈수 록 많아 지고 있다.복잡 한 웹 을 불 러 오 려 면 문서 도 있 고 그림 도 있 습 니 다. 여러 개의 요청, 즉 여러 개의 HTTP 통신 이 있어 야 합 니 다.HTTP 통신 을 한 번 하고 TCP 연결 을 한 번 끊 으 면 이러한 웹 을 불 러 옵 니 다. 여러 번 끊 고 TCP 를 다시 연결 해 야 하기 때문에 서버 에 불필요 한 비용 을 초래 합 니 다.그래서 '지속 적 인 연결 * *' 이 생 겼 습 니 다. 연결 을 끊 겠 다 는 명확 한 제안 이 없 으 면 TCP 연결 상 태 를 유지 합 니 다.HTTP / 1.1 기본 값 은 영구적 인 연결 입 니 다.
- * * 파이프라인 화 * * - 일반적으로 클 라 이언 트 가 요청 을 보 낸 후에 응답 을 받 은 후에 야 다음 요청 을 보 낼 수 있 습 니 다.파이프라인 화 기술 은 클 라 이언 트 가 응답 을 기다 리 지 않 고 다음 요청 을 직접 보 낼 수 있 도록 하 는 것 이다.이렇게 하면 여러 개의 요청 을 동시에 보 낼 수 있 고 응답 을 하나씩 기다 리 지 않 아 도 된다.
- * * HTTP 의 단점 과 HTTPS 의 등장 * * - HTTP 는 매우 우수 하지만 부족 한 점도 있 습 니 다. 예 를 들 어 다음 과 같 습 니 다.

(1) 통신 은 명문 (암호 화 되 지 않 음) 을 사용 하여 내용 이 도청 당 할 수 있다.

(2) 통신사 의 신분 을 검증 하지 않 아 위장 을 당 할 가능성 이 있다.

(3) 메시지 의 완전 성 을 증명 할 수 없 기 때문에 이미 변경 되 었 을 가능성 이 있다.

도청 을 막 기 위해 서 는 암호 화 기술 이 필요 하 다.방안 1 은 통신 암호 화, 안전 한 통신 선 로 를 구축 하고 안전 한 통신 을 하 는 것 이다.HTTP 자 체 는 암호 화 메커니즘 이 없어 SSL 와 TLS 조합 해서 사용 하면 안전 통신 을 완성 할 수 있다.방안 2 는 프로 토 콜 이 전송 하 는 내용 자 체 를 암호 화 하 는 것 이다. 클 라 이언 트 는 메 시 지 를 암호 화 한 후에 보 내 고 서버 가 요청 을 받 은 후에 메 시 지 를 복호화 한 다음 에 처리 할 것 이다.
HTTP 프로 토 콜 의 요청 과 응답 은 통신 측 에 확인 되 지 않 습 니 다.즉, '서버 가 요청 중 URI 가 진정 으로 지정 한 호스트 를 보 내 는 것 인지, 실제 요청 한 클 라 이언 트 로 되 돌아 오 는 응답 이 실제로 되 돌아 오 는 지' 등 유사 한 문제 가 존재 한 다 는 것 이다.클 라 이언 트 의 요청 이 위장 서버 에 도 착 했 을 수도 있 고 서버 에서 돌아 온 응답 이 위장 클 라 이언 트 에 게 되 돌 아 왔 을 수도 있 습 니 다.또한 이 밖 에 도 무의미 한 요청 도 조 단 이 모두 받 아들 여 대량의 요청 에 의 한 도스 공격 을 막 을 수 없다.이때 우 리 는 이 문 제 를 해결 하기 위해 '인증서' 를 사용 했다.SSL 은 암호 화 처리 뿐만 아니 라 인증서 메커니즘 도 제공한다.이 '인증서' 는 신뢰 할 수 있 는 제3자 인증 체제 가 발급 되 어 클 라 이언 트 와 서버 에 실제 존재 하 는 문제점 을 증명 한다.클 라 이언 트 가 서버 에 요청 하기 전에 서버 의 인증 서 를 확인 하고 서버 가 올 바른 서버 인지 판단 합 니 다.또한 클 라 이언 트 는 인증 서 를 가지 고 신분 확인 을 완성 하 는 데 사 용 됩 니 다.
HTTP 는 통신 메시지 의 완전 성 을 증명 할 수 없습니다. 클 라 이언 트 가 요청 할 때 메시지 와 서버 가 받 은 메시지 가 일치 하 는 지, 중간 에 변경 되 었 는 지 (중개인 공격) 를 보장 할 수 없습니다.만약 정말 이미 왜곡 되 었 다 면, 다른 한쪽 은 느 낄 수 없 을 것 이다.
HTTPS 의 필요 성: \ # \ #
HTTP 가 그 이상 부족 하기 때문에 더욱 완벽 한 통신 프로 토 콜 HTTPS 가 탄생 했다.HTTPS 는 SSL 케이스 를 입 은 HTTP 입 니 다.한 마디 로 HTTPS 가 더 안전 하 다.
* * HTTPS = HTTP + 통신 암호 화 + 인증서 + 완전 성 보호 * *
더 자세 한 정보: HTTPS 와 SSL (1)