HTTP를 기본으로 하는 프로토콜 HTTP의 병목현상을 해소하는 SPDY(스피디) - 사실상 사장된 기술 SPDY의 발전과 HTTP/2로의 전환:SPDY는 2010년 구글이 발표한 이후 웹 성능 향상에 큰 영향을 미쳤음그러나 SPDY 자체는 더 이상 활발히 사용되지 않음SPDY의 핵심 개념과 기술은 HTTP/2의 기반이 됨HTTP/2의 도입:2015년 HTTP/2가 공식적으로 표준화 됨HTTP/2는 SPDY의 많은 특징을 계승하여 개발 됨대부분의 주요 웹 브라우저와 서버는 HTTP/2를 지원 1. HTTP의 병목현상병목현상: 시스템의 전체 처리 능력이 가장 성능이 낮은 부분에 의해 제한되는 현상 연결 제한 (Connection Limit):HTTP/1.1은 일반적으로 브라우저당 도메인별로 동시 연결 수를..
인증을 무엇으로 할까?등록된 본인만이 알고 있는 정보등록한 본인만이 가지고 있는 정보 등패스워드, 원타임토큰, 전자증명서, 바이오매트릭스, IC카드HTTP에서 사용하는 인증방법BASICDIGESTSSL ClientForm Base1. BASIC 인증HTTP/1.0에 구현된 인증방식클라이언트: 리퀘스트 송신서버:상태코드 401로 응답해서 인증이 필요하다는 것을 전달유저가 ID와 패스워드를 입력하면, 브라우저가 자동적으로 Base64 로 변환클라이언트: 유저ID와 패스워드를 Base64형식으로 인코드 한 것을 송신서버: 인증 성공 시에는 상태코드 200 응답. 실패했을 경우 다시 상태코드 401로 응답서버는 인증정보가 정확한지 여부를 판단함단점: Base64라는 인코딩 형식을 사용하고 있지만, 암호화는 아님..
HTTP 약점평문(암호화 하지 않은) 통신이기 때문에 도청 가능통신 상대를 확인하지 않기 때문에 위장 가능완전성을 증명할 수 없기 때문에 변조 가능 1. 평문이기 때문에 도청 가능TCP/IP는 도청 가능한 네트워크암호화로 도청 피할 수 있다통신을 암호화 : HTTP + SSL/TLS 조합SSL(Secure Socket Layer)TLS(Transport Layer Security)SSL 등을 이용해 안전한 통신로를 확립 후, 그 통신로를 사용해 HTTP 통신SSL을 조합한 HTTP => HTTPS(HTTP Secure) / HTTP over SSL콘텐츠 암호화: 콘텐츠 내용 자체를 암호화(HTTP메시지에 포함되는 콘텐츠만 암호화)메시지 헤더는 암호화되어 있지 않음메시지 바디에 들어가는 콘텐츠를 암호화(통..
리퀘스트 HTTP 메시지HTTP 메시지 헤더클라이언트와 서버 처리에 필요한 주요정보 거의 다 여기 있다개행문자 HTTP 메시지 바디사용자와 리소스를 필요로 하는 정보가 있다 HTTP 헤더 필드 구조헤더필드 명: 필드 값일반 헤더 필드: 리퀘스트 메시지와 리퀘스트 메시지 둘 다 사용 됨리퀘스트 헤더 필드: 리퀘스트 부가정보와 클라이언트 정보, 리스폰스의 콘텐츠 관련 우선순위 등 포함리스폰스 헤더 필드: 리스폰스의 정보와 서버경로, 클라이언트 추가 정보요구 등 포함엔티티 헤더 필드: 콘텐츠 갱신시간 등 엔티티 관련 정보 포함HTTP/1.1 이외의 헤더 필드(비표준 헤더 필드)쿠키와 Set-Cookie, Content-DispositionEnd- to-end 헤더와 Hop-by-hop 헤더HTTP 헤더필드는..
웹 서버는 1대의 서버에서 멀티도메인으로 웹사이트를 실행하거나, 중계서버를 두어 통신 중 효율을 올릴 수 있다. 가상호스트하나의 HTTP서버에 여러개의 웹 사이트 실행 가능(HTTP/1.1) - 가상호스트 기능가상호스트 기능: 물리적으로 서버는 1대, 가상으로 여러 대 있는 것 처럼 설정 통신 중계 프로그램통신 중계 프로그램과 서버는 그 다음에 있는 다른 서버에 리퀘스트 중계그 서버로부터 받은 리스폰스를 클라이언트에 반환하는 역할을 담당 프록시서버와 클라이언트 양쪽 역할 중계클라이언트로부터 서버에 리퀘스트 전송클라이언트의 리퀘스트 URI를 변경하지 않고 서버에 전송서버로부터 클라이언트에 리스폰스 전송프록시 서버를 사용하는 이유캐시를 사용해서 네트워크 대역 등 효율적 사용을 위해조직 내 특정 웹 사이트에 ..
상태코드 클래스클라이언트가 보낸 요청에 대한 서버의 응답을 나타내는 세 자리 숫자요청이 성공했는지, 실패했는지, 또는 추가 작업이 필요한지를 나타냄 클래스설명1xxInformational리퀘스트를 받아들여 처리 중2xxSuccess리퀘스트를 정상적으로 처리 했음3xxRedirection리퀘스트를 완료하기 위해 추가 동작이 필요함4xxClient Error서버는 리퀘스트 이해 불가능5xxServer Error서버는 리퀘스트 처리 실패함 100 Continue: 클라이언트가 요청을 계속할 수 있음. 서버는 요청의 일부를 받았고 클라이언트가 나머지를 보내기를 기다리고 있음101 Switching Protocols: 서버가 클라이언트의 요청에 따라 프로토콜을 변경하고 있음 200 OK: 요청이 성공적으로 처리..
1. HTTP 메시지메시지 구조 = 메시지 헤더 + 개행문자 + 메시지 바디메시지 헤더: 서버와 클라이언트가 꼭 처리해야 하는 리퀘스트와 리스폰스 내용과 속성 등개행문자[CR+LF] : Carrage Return(CR) + Line Feed(LF)메시지 바디: 꼭 전송되는 데이터 그 자체 2. 리퀘스트 메시지와 리스폰스 메시지의 구조리퀘스트 메시지메시지헤더리퀘스트라인 = 메소드 + 리퀘스트 URI + HTTP버전리퀘스트 헤더필드일반 헤더필드엔티티 헤더필드그 외 헤더필드 (쿠키 등)개행문자메시지바디리스폰스 메시지메시지헤더상태라인 = 상태코드 + 상태코드설명 + HTTP버전리스폰스 헤더필드일반 헤더필드엔티티 헤더필드그 외 헤더필드 (쿠키 등)개행문자메시지바디그 외 헤더필드: HTTP의 RFC 문서에는 정의되..
엔티티 바디(Entity Body)전송하려는 실제 데이터(payload)JSON 데이터, 텍스트, 이미지 등 모든 형태의 데이터 가능메시지 바디(Message Body)HTTP 프로토콜을 통해 전송되는 데이터엔티티 바디를 포함 함엔티티 바디가 인코딩(압축 등)될 수 있음JSON 데이터 전송 예시POST /submit HTTP/1.1Host: example.comContent-Type: application/jsonContent-Length: 27{ "name": "John", "age": 30}엔티티 바디: {"name": "John", "age": 30} (전송하려는 실제 데이터)메시지 바디: 엔티티 바디가 포함된 HTTP 메시지의 일부분. 이 경우에는 인코딩되지 않았으므로 엔티티 바디와 동일 단순..
