http 프로 토 콜 상세 설명(초 상세)
7947 단어 http 프로 토 콜 상세 설명
1. 기초 개념 편
소개
HTTP 는 Hyper Text Transfer Protocol(하이퍼텍스트 전송 프로 토 콜)의 줄 임 말이다.그 발전 은 유 니 버 설 네트워크 협회(World Wide Web Consortium)와 인터넷 작업 팀 IETF(Internet Engineering Task Force)가 합작 한 결과(그들)는 최종 적 으로 일련의 RFC 를 발 표 했 고 RFC 1945 는 HTTP/1.0 버 전 을 정의 했다.그 중 가장 유명한 것 은 RFC 2616 이다.RFC 2616 은 오늘날 보편적으로 사용 되 는 버 전인 HTTP 1.1 을 정의 했다.
HTTP 프로 토 콜(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 작업 은 하나의 업무 라 고 하 는데 그 작업 과정 은 네 단계 로 나 눌 수 있다.
1)우선 클 라 이언 트 와 서버 가 연결 되 어야 합 니 다.하이퍼링크 를 누 르 면 HTTP 작업 이 시 작 됩 니 다.
2)연결 을 만 든 후 클 라 이언 트 는 서버 에 요청 을 보 냅 니 다.요청 방식 의 형식 은 자원 식별 자(URL),프로 토 콜 버 전 번 호 를 통일 하고 뒤쪽 은 MIME 정보 입 니 다.수식 자,클 라 이언 트 정보 와 가능 한 내용 을 포함 합 니 다.
3)서버 가 요청 을 받 은 후에 해당 하 는 응답 정 보 를 제공 합 니 다.그 형식 은 하나의 상태 줄 입 니 다.정보의 프로 토 콜 버 전 번호,성공 또는 오류 코드 를 포함 하고 뒤쪽 은 MIME 정 보 는 서버 정보,실체 정보 와 가능 한 내용 을 포함 합 니 다.
4)클 라 이언 트 는 서버 가 되 돌아 오 는 정 보 를 브 라 우 저 를 통 해 사용자 의 디 스 플레이 에 표시 한 다음 에 클 라 이언 트 와 서버 가 연결 을 끊 는 다.
상기 과정 에서 한 단계 에 오류 가 발생 하면 오류 가 발생 한 정 보 는 클 라 이언 트 로 돌아 가 디 스 플레이 출력 이 있 습 니 다.사용자 에 게 이러한 과정 은 HTTP 가 스스로 완성 한 것 으로 사용 자 는 마우스 로 클릭 하고 정보 가 표시 되 기 를 기다 리 면 된다.
1.5 Wireshark 로 TCP,http 패키지 잡기
Wireshark 를 열 고 도구 모음 에 있 는"Capture"->"Options"를 선택 하 십시오.화면 선택 은 그림 1 과 같 습 니 다.
그림 1 캡 처 옵션 설정
일반 독 자 는 맨 위 에 있 는 드 롭 다운 상자 만 선택 하고 적합 한 장 치 를 선택 한 다음'Capture Filter'를 클릭 합 니 다.여기 서 선택 한 것 은'HTTP TCP port(80)'입 니 다.선택 한 후 위의 그림 의'Start'를 클릭 하여 스냅 백 을 시작 합 니 다.
그림 2 캡 처 필터 선택
예 를 들 어 브 라 우 저 에서 열기http://image.baidu.com/,스냅 백 은 그림 3 참조:
그림 3 핸드백
위의 그림 에서 클 라 이언 트 브 라 우 저(ip 은 192.168.2.33)와 서버 의 상호작용 과정 을 뚜렷하게 볼 수 있다.
1)No1:브 라 우 저(192.168.2.33)가 서버(220.181.50.118)에 연결 요청 을 합 니 다.이것 은 TCP 세 번 의 악수 첫 번 째 단계 입 니 다.그림 에서 보 듯 이 SYN,seq:X(x=0)입 니 다.
2)No2:서버(220.181.50.118)가 브 라 우 저(192.168.2.33)의 요청 에 응답 하고 확인 을 요 구 했 습 니 다.이 때 는 SYN,ACK,이때 seq:y(y 는 0),ACK:x+1(1)입 니 다.세 번 의 악수 의 두 번 째 단계;
3)No3:브 라 우 저(192.168.2.33)가 서버(220.181.50.118)의 확인 에 응 하여 연결 에 성공 했다.위:ACK,이때 seq:x+1(1),ACK:y+1(1).세 번 째 악수 의 세 번 째 단계;
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)확인;
8)No 14:클 라 이언 트(192.168.2.33)가 그림 HTTP 요청 을 보 냅 니 다.
9)No 15:서버(220.181.50.118)전송 상태 응답 코드 200 OK
……
1.6 헤드 필드
각 도 메 인 은 도 메 인 이름,콜론(:)과 도 메 인 값 세 부분 으로 구성 되 어 있 습 니 다.도 메 인 이름 은 대소 문자 와 무관 합 니 다.도 메 인 값 전에 빈 칸 을 추가 할 수 있 습 니 다.머리 도 메 인 은 여러 줄 로 확장 할 수 있 습 니 다.줄 마다 시작 할 때 최소한 하나의 빈 칸 이나 탭 문 자 를 사용 할 수 있 습 니 다.
가방 을 잡 는 그림 에서 No 14 시 에 열 면 그림 4 참조:
그림 4 http 요청 메시지
응답 하 는 메 시 지 는 그림 5 참조:
그림 5 http 상태 응답 정보
1.6.1 호스트 헤드 필드
Host 헤드 필드 는 요청 자원 의 Intenet 호스트 와 포트 번 호 를 지정 합 니 다.url 을 요청 하 는 원본 서버 나 게 이 트 웨 이 위 치 를 표시 해 야 합 니 다.HTTP/1.1 요청 은 호스트 헤드 필드 를 포함해 야 합 니 다.그렇지 않 으 면 시스템 이 400 상태 코드 로 돌아 갑 니 다.
그림 5 에서 host 의 행동:
1.6.2 레 퍼 헤드 필드
Referer 헤드 필드 는 클 라 이언 트 가 uri 를 요청 하 는 소스 자원 주 소 를 지정 할 수 있 습 니 다.이것 은 서버 가 반환 링크 를 생 성 할 수 있 고 로그 인,cache 최적화 등에 사용 할 수 있 습 니 다.그 도 폐지 되 거나 잘못된 연결 을 허용 했다.요청 한 uri 에 자신의 uri 주소 가 없 으 면 Refer 는 보 낼 수 없습니다.일부 uri 주 소 를 지정 하면 이 주 소 는 상대 적 인 주소 여야 합 니 다.
그림 4 에서 Refer 줄 의 내용 은:
1.6.3 사용자 에이전트 헤드 필드
User-agent 헤드 필드 의 내용 은 요청 한 사용자 정 보 를 포함 합 니 다.
그림 4 에서 User-agent 줄 의 내용 은:
1.6.4 Cache-Control 헤드 필드
Cache-Control 은 요청 과 응답 을 따 르 는 캐 시 메커니즘 을 지정 합 니 다.요청 메시지 나 응답 메시지 에 Cache-Control 을 설정 하면 다른 메시지 처리 과정 에서 캐 시 처리 과정 을 수정 하지 않 습 니 다.요청 할 때의 캐 시 명령 은 no-cache,no-store,max-age,max-stale,min-fresh,only-if-cache 를 포함 하고 응답 메시지 의 명령 은 Public,private,no-cache,no-store,no-transform,must-revalidate,proxy-revidate,max-age 를 포함한다.
그림 5 의 이 헤드 필드 는:
1.6.5 Date 헤드 필드
Date 헤드 필드 는 메시지 가 보 내 는 시간 을 표시 합 니 다.시간의 설명 형식 은 rfc 822 에 의 해 정 의 됩 니 다.예 를 들 어 Date:Mon,31Dec200104:25:57GMT.Date 가 설명 한 시간 은 세계 표준 을 나 타 낼 때 원가 지 시간 을 환산 하고 사용자 가 있 는 시간 대 를 알 아야 합 니 다.
그림 5 에서 이 두 역 은 다음 그림 과 같다.
1.7 HTTP 의 몇 가지 중요 한 개념
1.7.1 연결:연결
서로 통신 하 는 두 프로그램 사이 에 세 워 진 전송 층 의 실제 환류
http 1.1,request 와 reponse 헤드 에 connection 의 헤더 가 나타 날 수 있 습 니 다.이 header 는 client 와 server 가 통신 할 때 긴 링크 를 어떻게 처리 하 는 지 의미 합 니 다.
http 1.1 에서 client 와 server 는 기본적으로 상대방 이 긴 링크 를 지원 합 니 다.client 가 http 1.1 프로 토 콜 을 사용 하지만 긴 링크 를 사용 하지 않 으 려 면 header 에서 connection 의 값 을 close 로 표시 해 야 합 니 다.서버 측 도 긴 링크 를 지원 하지 않 으 려 면 response 에서 도 connection 의 값 이 close 라 는 것 을 명확 하 게 설명해 야 합 니 다.request 든 response 의 header 에 close 값 의 connection 이 포함 되 어 있 든 현재 사용 하고 있 는 tcp 링크 는 당일 요청 처리 가 완료 되면 끊 어 집 니 다.나중에 client 에서 새로운 요청 을 할 때 새로운 tcp 링크 를 만들어 야 합 니 다.
1.7.2 메시지:메시지
HTTP 통신 의 기본 단 위 는 구조 화 된 8 원 그룹 서열 을 포함 하고 연결 을 통 해 전송 된다.
1.7.3 요청:요청
클 라 이언 트 에서 서버 까지 의 요청 정 보 는 자원 에 사용 하 는 방법,자원 의 식별 자 와 프로 토 콜 의 버 전 번 호 를 포함한다.
1.7.4 응답:응답
서버 에서 돌아 오 는 정 보 는 HTTP 프로 토 콜 의 버 전 번호,요청 한 상태(예 를 들 어'성공'또는'찾 을 수 없 음')와 문서 의 MIME 형식 을 포함 합 니 다.
1.7.5 자원:자원
URI 로 표 시 된 네트워크 데이터 대상 이나 서비스.
1.7.6 실체:Entity
데이터 자원 이나 서비스 자원 에서 반 영 된 특수 한 표현 방법 은 요청 이나 응답 정보 에 둘러싸 일 수 있 습 니 다.하나의 실 체 는 실체 헤드 정보 와 실체의 자체 내용 을 포함한다.
1.7.7 클 라 이언 트:Client
요청 을 보 내기 위해 연결 을 만 드 는 프로그램
1.7.8 사용자 에이전트:UserAgent
요청 한 클 라 이언 트 를 초기 화 합 니 다.브 라 우 저,편집기 또는 다른 사용자 도구 입 니 다.
1.7.9 서버:서버
연결 을 받 아들 이 고 정 보 를 되 돌려 달라 고 요청 하 는 프로그램
1.7.10 소스 서버:Originserver
주어진 자원 이 그 위 에 머 무 르 거나 만 들 수 있 는 서버 입 니 다.
1.7.11 에이전트:프 록 시
중간 프로그램 은 서버 를 충당 할 수도 있 고,클 라 이언 트 를 충당 할 수도 있 으 며,다른 클 라 이언 트 를 위해 요청 을 할 수도 있다.요청 은 가능 한 번역 을 통 해 내부 나 다른 서버 에 전 달 됩 니 다.요청 메 시 지 를 보 내기 전에 설명 하고 다시 쓸 수 있 는 에이전트 가 있어 야 합 니 다.
대 리 는 항상 방화벽 을 통과 하 는 클 라 이언 트 기기 의 포 털 로 서 대 리 는 사용자 가 대리 하지 않 은 요청 을 협의 로 처리 하 는 데 도움 을 줄 수 있다.
1.7.12 게 이 트 웨 이
다른 서버 의 중간 매개체 가 되 는 서버프 록 시 와 달리 게 이 트 웨 이 가 요청 을 받 아들 이 는 것 은 요청 한 자원 에 있어 서 원본 서버 인 것 같 습 니 다.요청 을 한 클 라 이언 트 는 게 이 트 웨 이와 접촉 하고 있다 는 것 을 의식 하지 못 했다.
게 이 트 웨 이 는 항상 방화벽 을 통과 하 는 서버 엔 드 의 포 털 로 서 게 이 트 웨 이 는 비 HTTP 시스템 에 저 장 된 자원 을 액세스 할 수 있 도록 프로 토 콜 번역기 로 도 사용 할 수 있다.
1.7.13 채널:Tunnel
두 개의 연결 중 계 를 위 한 중개 프로그램 입 니 다.활성화 되면 채널 은 HTTP 통신 에 속 하지 않 는 것 으로 여 겨 집 니 다.비록 채널 이 HTTP 요청 에 의 해 초기 화 될 수 있 지만.중 계 된 연결 양 끝 이 닫 히 면 채널 이 사라 집 니 다.포 털(Portal)이 존재 하거나 중개(Intermediary)가 중계 통신 을 설명 하지 못 할 때 채널 이 자주 사용 된다.
1.7.14 캐 시:캐 시
반응 정보의 국 역 저장.
좋은 웹페이지 즐겨찾기
