-
Notifications
You must be signed in to change notification settings - Fork 1
http_study_01
http/1.1 버전이 가장 많이 사용된다. 1997년 1월 공개되었으며 RFC2616이 최신 사양이다.
프로토콜의 집합이다. 인터넷과 관련된 프로토콜을 모은 것을 TCP/IP라고 부른다. IP 프로토콜을 사용한 통신에서 사용되고 있는 프로토콜을 총칭해 TCP/IP 프로토콜이라 한다.
계층은 다음과 같이 구성된다.
-
애플리케이션
- HTTP 메시지
-
트랜스포트
-
TCP
-
TCP 세그멘토
-
애플리케이션에서 받은 HTTP 메시지를 통신하기 쉽게 조각내 안내 번호/포트 번호를 붙여 전달
-
-
네트워크
-
IP
-
IP 데이터그램
-
수신지 MAC 주소 추가해 전달
-
-
링크
- 네트워크 프레임
각 계층을 거칠 때마다 헤더로 불리는 필요 정보 추가. 받을 때는 계층마다 사용한 헤더 삭제. 정보를 감싸 전달하는 것이 캡슐화임
개개의 패킷을 상대방에게 전달하는 것이 역할. IP 주소는 각 노드에 부여된 주소를 가리키며, MAC 주소는 네트워크 카드에 할당된 고유주소.
MAC주소는 변경 불가임
IP통신은 MAC 주소에 의존해 통신한다.
중계할 곳의 목적지를 찾기 위해 ARP(Address Resolution Protocol)을 사용하낟.
신뢰성 있는 바이트 스트림 서비스 제공. 바이트 스트림 서비스란 데이터를 TCP 세그먼트란 단위 패킷으로 작게 분하해여 관리하는 것. 즉, 작가 분해하여 보내고, 정확하게 도착했는지 확인하는 것이 역할임
three way handshaking 을 사용함.
도메인명에서 IP 주소 조사 <-> IP주소로부터 도메인명 조사
Uniform Resource Identifiers
URL은 리소스를 식별하기 위해 문자열 전반을 나타냄 URL은 리소스의 장소(네트워크 상 위치)를 나타냄
URL은 URI의 서브셋임
HTTP는 stateless 프로토콜임. 과거 교환했던 리퀘스트/리스폰스 상태를 관리하지 않음.
쿠키라는 시스템 도입
쿠키는 서버에서 리스폰스로 보내진 Set-Cookie라는 헤더 필드에 의해 쿠키를 클라이언트에 보존
클라이언트가 같은 서버로 보낼 때 자동으로 쿠키 값 다시 넣어서 송신. 서버는 쿠키값 확인해 어느 클라이언트가 접속했는지 체크
크게 메시지 헤더와 메시지 바디로 구성되어 있다. 최초 나타나는 개행 문제(CR+LF)로 둘을 구분한다. 이 안에 메시지 바디가 항상 존재하는건 아니다.
전송할 때 인코딩을 실시해 전송 효율을 높인다.
메시지는 HTTP 통신의 기본 단위로 옥텟 시퀀스로 구성되며 통신을 통해 전송된다.
엔티티는 리퀘스트, 리스폰스의 페이로드로 전송되는 정보로 엔티티 헤더 필드와 엔티티 바디로 구성된다.
기본적으로 메시지 바디와 엔티티 바디는 같지만 전송 코딩이 적용되면 엔티티 바디의 내용이 변한다.
-
Content Codings : 압축
-
Chunked transfer Coding : 엔티티 바디를 분할해 보냄
MIME(Multipurpose Internet Mail Extensions) : 메일로 텍스트, 영상, 이미지와 같은 다른 데이터를 다루기 위한 기능
MIME 확장 사양에 Multipart라고 하는 여러 다른 종류의 데이터를 수용하는 방법을 사용하고 있다.
HTTP도 멀티파트에 대응하고 있어 메시지 바디 내부에 엔티티를 여러 개 포함시켜 보낼 수 있다.
Range Request : 엔티티의 범위를 지정하여 리퀘스트 할 수 있다.
Contents Negotiation
클라이언트가 서버를 향해 리퀘스트를 보낼 때 서버에서 그 결과가 어떻게 되었는지 알려주는 것이 상태 코드의 역할이다.
상태코드클래스
-
1xx : Informational
-
2xx : Success
-
3xx : Redirection
-
4xx : Client Error
-
5xx : Server Error
1대로 멀티 도메인을 가능하게 함. DNS에 의해 IP 주소로 변환되고 액세스. 리퀘스트가 서버에 도착한 시점에는 IP 주소를 기준으로 액세스. 같은 IP 주소에서 다른 호스트명과 도메인 명을 가진 여러 개의 웹 사이트가 실행되고 있는 가상 호스트의 시스템이 있으므로, HTTP 리퀘스트를 보내는 경우에는 호스트명과 도메인 명을 완전하게 포함한 URI 를 지정하거나, 반드시 Host 헤더 필드에서 지정해야
서버-클라이언트 역할 중계. 리소스 본체를 가진 서버를 Origin Server라 부른다. 여러 대 경유하는 것도 가능하며, Via 헤더 필드에 호스트 정보가 추가된다.
캐시, 네트워크 대역 효율적 사용, 특정 웹사이트 액세스 제한, 액세스 로그 획득 정책 등을 철저히 지키기 위한 목적으로도 사용된다.
사용방법
-
Caching Proxy
- 프록시 서버 상에 리소스 캐시 보존
-
Transparent Proxy
-
중계 시 메시지 변경을 하지 않음.
-
반대로 변경하면 비투과 프록시라 함
-
프록시와 유사. HTTP 서버 이외의 서비스를 제공하는 서버를 중계해줌. 클라이언트-게이트웨이 사이를 암호화하는 등으로 안전하게 접속함으로써 통신의 안정성을 높이는 역할.
ex) DB 접속해 SQL 쿼리 사용, 쇼핑 사이트에서 신용 카드 결제 시스템과 연동 등
요구에 따라 다른 서버와 통신 경로 확립
HTTP의 단점
-
평문 통신이므로 도청 가능
-
통신 상대를 확인하지 않으므로 위장 가능
-
완전성 증명 불가하므로 변조 가능
통신 암호화로 위의 단점을 피할수는 있으나 문제 있음
HTTP + 암호화, 인증, 완전성 보호 = HTTPS(HTTP Secure)
HTTP 통신을 하는 소켓 부분을 SSL(Secure Socket Layer)이나 TLS(Transport Layer Security)라는 프로토콜로 대체하고 있을 뿐이다.
간단하게, SSL이라는 껍질을 덮어쓴 HTTP가 HTTPS인 것이다.
암호화나 복호화에 하나의 키를 같이 사용하는 방식을 공통키 암호라고 한다.
암호를 보내는 측이 상대의 공개키를 사용해 암호화. 받아들인 상대는 자신의 비밀키를 사용해 복호화. 비밀키를 통신으로 보내지 않으므로 키를 빼앗길 염려가 없다.
암호문/공개키 정보에서 평문 구하는 것은 오래 걸리므로 해독이 쉽지 않음
HTTPS는 공통키 + 공개키 암호 양쪽 성질을 다 가짐
키를 교환하는 곳에서는 공개키 암호 사용, 그 후 통신에선 공통키 사용
HTTP/1.1 에서 사용 가능한 인증 방식
-
BASIC
- BASE64 인코드로 ID:PASSWORD Authorization 헤더 필드에 포함해 리퀘스트 송신
-
DIGEST
-
챌린지 리스폰스 방식
-
최초에 상대방에게 인증 요구를 보내고 상대방 측에서 받은 챌린지 코드를 사용해 리스폰스 코드를 계산. 이 값을 상대에게 송신하여 인증
-
-
SSL 클라이언트
-
HTTPS 클라이언트 인증서를 이용한 인증 방법
-
2-factor 인증에서 사용된다. 패스워드라는 한 개의 요소만이 아닌 이용자가 가진 다른 정보를 병용해서 인증을 하는 방법이다.
-
-
폼 베이스
- 서버 상의 웹 애플리케이션에 자격 정보를 송신하여 그 자격 정보의 검증 결과에 따라 인증을 하는 방식
-
통합 Windows 인증(Kerberos 인증, NTML 인증 등)
구글이 제안한 프로토콜. HTTP를 완전히 바꿔 놓는 것은 아님. TCP/IP의 애플리케이션 계층과 트랜스포트 계층 사이에 새로운 세션 계층을 추가하는 형태로 동작함. 보안을 위해 표준으로 SSL을 사용함.
HTML5의 사양의 일부로 책정되었지만, 현재는 단독 프로토콜로 규격 책정. RFC6455
웹 브라우저와 웹 서버를 위한 양방향 통신 규격.
웹서버-클라이언트가 한 번 접속을 확립하면, 그 뒤의 통신을 모두 전용 프로토콜로 하는 방식. 임의 형식의 데이터(JOSN , ...)을 보내게 됨. 접속의 출발점은 클라이언트라는건 같지만, 한 번 접속 확립 시 WebSocket을 사용해 어느 쪽에서도 송신 가능함.