HTTP

✔ 캐시 제어 헤더 Cache-Control 캐시 제어 Pragma 캐시 제어(하위 호환) Expires 캐시 유효 기간(하위 호환) Cache-Control (캐시 지시어) Cache-Control: - HTTP 1.1에서 추가된 기능으로, 여러 캐싱 정책을 다양하게 제공 - 최근에는 ETag와 Cache-Control을 사용하여 컨텐츠 캐싱을 수행하는 추세다 max-age 캐시 유효 시간, 초 단위 예를 들어 60 _ 60 = 3600을 입력하면 한 시간, 3600 _ 24 = 86400을 입력하면 하루동안 캐시 유지 이후엔 서버에 요청한 뒤 304 응답을 받을 때에만 캐시를 이용한다 no-cache 캐시가 유효한지 확인하기 위해 매번 원 서버에 요청을 보낸다 여기서 원 서버라는 말은, 프록시 서버(..

✔ 특별한 Header 정보 Host 요청한 호스트 정보, 도메인(요청) Location 페이지 리다이렉션(응답) Allow 허용 가능한 HTTP 메서드(응답) Retry-After 유저 에이전트가 다음 요청을 하기까지의 걸리는 시간(응답) Host GET /search?q=hello&hl=ko HTTP/1.1 Host: www.google.com(Header) 요청한 호스트 정보(도메인) 요청에서 사용 필수 Header 정보로, 가장 중요한 정보다 하나의 서버가 여러 도메인을 처리할 때 사용 하나의 IP 주소에 여러 도메인이 적용되어 있을 때 하나의 서버가 여러 도메인을 처리해야 할 경우? 가상호스트를 통해 여러 도메인을 한번에 처리할 수 있는 서버로, 실제 애플리케이션이 여러개 구동될 수 있다 하나의..

✔ 클라이언트에서 서버로 데이터 전송 데이터 전달 방식은 크게 2가지 쿼리 파라미터를 통한 데이터 전송 GET 주로 정렬 필터(검색어) 메시지 바디를 통한 데이터 전송 POST, PUT, PATCH 회원 가입, 상품 주문, 리소스 등록, 리소스 변경 데이터 전달 4가지 상황 정적 데이터 조회: 이미지, 정적 텍스트 문서 동적 데이터 조회: 주로 검색, 게시판 목록에서 정렬 필터 (검색어) HTML Form을 통한 데이터 전송: 회원 가입, 상품 주문, 데이터 변경 HTTP API를 통한 데이터 전송: HTML Form을 사용하지 않는 모든 상황 (Ajax) 회원 가입, 상품 주문, 데이터 변경 서버 to 서버, 앱 클라이언트, 웹 클라이언트 (Ajax) 정적 데이터 조회 쿼리 파라미터 미사용 이미지, 정..

✔ HTTP Header 캐시 캐시가 없는 경우(요청 예시) #요청 GET /star.jpg #응답 HTTP/1.1 200 OK Content-Type: image/jpeg Content-Length: 34012 lkj123kjddhdudieidjskskdhdjd987snshsjdksjdjskdjakasks skskdjdjsjkdkd938372sksksks;oisjsjdkds;skskdl; GET 요청을 통해 star.jpg 이미지 요청 서버는 GET 요청에 맞는 이미지를 내려준다 이때 헤더와 바디의 용량은 아래와 같다 HTTP 헤더: 0.1M HTTP 바디: 1.0M 캐시를 사용하지 않는다면? 서버는 헤더와 바디를 매번 생성하여 클라이언트에 전달을 해야한다 데이터가 변경되지 않아도 계속 네트워크를 통해..

✔ 콘텐츠 협상(Content Negotiation) 클라이언트가 선호하는 표현 요청: Accept: 클라이언트가 원하는 미디어 타입 전달 Accpet-Charset: 클라이언트가 원하는 문자 인코딩 Accept-Encoding: 클라이언트가 원하는 압축 인코딩 Accept-Language: 클라이언트가 원하는 자연 언어 협상 헤더는 요청시에만 사용 클라언트가 원하는 방식으로 서버에 요청하는 방식 Accept-Language 적용 전 GET /event Accept-Language: ko 한국어 브라우저를 사용하는 클라이언트 측에서 서버에 요청을 보낸다 Content-Language: ko 안녕하세요 다중 언어를 지원하는 서버는 Accept-Language를 보고 언어에 맞는 데이터 반환 Accept-L..

✔ 일반 Header 정보 From 유저 에이전트의 이메일 정보 Referer 이전 웹 페이지 주소 User-Agent 유저 에이전트 애플리케이션 정보 Server 요청을 처리하는 오리진 서버의 소프트웨어 정보 Date 메시지 생성 날짜 From 유저 에이전트의 이메일 정보 일반적으로 잘 사용 안함 검색 엔진 같은 곳에서, 주로 사용 요청에서 사용 Referer 이전 웹 페이지 주소 현재 요청된 페이지의 이전 웹 페이지 주소 A -> B로 이동하는 경우 B를 요청할 때 Referer: A를 포함해서 요청 요청에서 사용 유입 경로(이전 웹 브라우저 페이지)를 분석할 경우 많이 사용이 된다 User-Agent 클라이언트 애플리케이션 정보 user-agent: Mozilla/5.0 (Macintosh; Int..

✔ HTTP 헤더 #1: RequestGET /search?q=hello&hl=ko HTTP/1.1Host: www.google.com #header#2: ResponseHTTP/1.1 200 OKContent-Type: text/html;charset=UTF-8Content-Length: 3423 #header ... header-field = field-name “:” OWS field-value OWS (OWS: 띄어쓰기 허용) field-name은 대소문자 구분 없음 HTTP 헤더의 용도 HTTP 전송에 필요한 모든 부가정보 메시지 바디 내용, 크기, 압축, 인증, 요청 클라이언트, 서버 정보, 캐시 관리정보 표준 헤더가 너무 많음 필요시 임의의 헤더 추가 가능 helloworld: hihi HT..

10. ✔ 인증 완벽한 인증은 없으며, 비밀번호는 유출이되고, 신분증은 위조가 된다 완벽한 인증은 존재하지 않는다, 거대한 인터넷 내에서의 보안(인증)은 필수적이다 HTTP 기본 인증 과정을 정리하며 인증에 대해 정리 해보자 ✔ HTTP 인증요구 기본 인증 기본 인증은 가장 잘 알려진 HTTP 인증 규약 기본 인증의 경우 서버는 클라이언트의 요청을 거부하고 추가적인 데이터를 요구할 수 있다 서버는 401 상태 코드와 클라이언트가 접근하려했던 부분을 WWW-Authenticate에 적어 반환 Authorization 클라이언트 인증 정보 비밀번호, 개인정보, 등을 서버에 전달 WWW-Authenticate 리소스 접근시 필요한 인증 방법 정의 서버에서 요청을 받은 후 응답을 내려줄 때 같이 반환 요청 과정..

✔ 웹 서비스가 작동하기 위한 수 많은 약속들 데이터를 주고받는 약속은 2가지로 구분이 된다 TCP / UDP TCP/UDP TCP (전화기) 1 : 1 연결만 가능 데이터가 손실되면 재전송 요청을 하므로, 신뢰성 높음 데이터의 순서와 무결성 보장 속도가 상대적으로 느림 높은 신뢰도를 요한 서비스에 적합 UDP (라디오) 1: N 연결 가능 정보를 받았는지 확인치 않고 일방적으로 전송 데이터의 순서와 무결성 보장하지 않음 속도가 상대적으로 빠름 IPTV, 실시간 스트리밍에 적합 ✔ 브라우저 요청 흐름 https://www.google.com:443/생략 입력 시 어떻게 페이지를 반환하는 것인가? 웹 브라우저 서버 요청 과정 웹 브라우저는 DNS 서버 조회를 통해 200.200.200.2(구글 서버) 결과..

✔ HTTP 상태코드 클라이언트가 보낸 요청의 처리 상태를 응답을 통해 알려주는 기능 1xx (Informational) 요청이 수신되어 처리중 2xx (Successful) 요청 정상 처리 3xx (Redirection) 요청을 완료하려면 추가 행동 필요 4xx (Client Error) 클라이언트 오류, 잘못된 문법등으로 서버가 요청 처리 불가 5xx (Server Error) 서버 오류, 서버가 정상 요청을 처리 못함 만약 모르는 상태 코드가 나타나면? 클라이언트가 인식할 수 없는 상태코드를 서버가 반환? 클라이언트는 상위 상태코드로 해석 후 처리 미래에 새로운 상태 코드가 추가되어도 클라이언트를 변경하지 않아도 됨 ex) 299 ??? → 2xx (Successful) 451 ??? → 4xx (..

✔ 데이터를 주고받기 위한 규약 HTTP 웹 상에서 데이터를 주고받기 위한 규칙 중 하나인 HTTP의 전체 흐름 파악 HTTP 메시지에 모든 것을 포함해 전송 HTML, TEXT IMAGE, 음성, 영상, 파일 JSON, XML (API) 거의 모든 형태의 데이터 전송 가능 서버간에 데이터를 주고 받을 때도 대부분 HTTP 사용 지금은 HTTP 시대라 해도 과언이 아니다 HTTP의 역사 HTTP/0.9 1991년 : GET 메서드만 지원, HTTP 헤더 x HTTP/1.0 1996년 : 메서드, 헤더 추가 HTTP/1.1 1997년 : 가장 많이 사용, 우리에게 가장 중요한 버전 RFC2068 (1997) → RFC2616 (1999) → RFC7230 ~ 7235 (2014) HTTP/2 2015년 :..

✔ URI & URL URI과 URL은 해당 자원의 위치를 식별하기 위해 사용되는 규칙이다 URI(Uniform Resource Identifier) Uniform: 리소스를 식별하기 위한 통일된 규칙 Resource: URI로 식별할 수 있는 모든 자원(제한 없음) 실시간 교통 정보 HTML 우리가 구분할 수 있는 모든 것 Identifier: 다른 항목과 구분하는데 필요한 정보 URL(Uniform Resource Locator) 리소스가 있는 위치를 지정 URN(Uniform Resource Name) 리소스에 이름 부여 위치는 변할 수 있지만, 이름은 변하지 않는다. urn:isbn:8960777331 (어떤 책의 isbn URN) URN 이름만으로 실제 리소스를 찾을 수 있는 방법이 보편화 되지..