[Network] 네트워크 용어 정리

IP란?

지정한 IP 주소에 패킷단위로 데이터를 전달하는 인터넷 규칙입니다. 클라이언트는 전송데이터를 보내기 전에 출발 IP와 목적 IP를 지정해야하고 데이터를 패킷이라는 통신단위를 통해 서버에게 전달합니다. 반대로 서버는 패킷을 잘 전달 받았다는 응답을 출발 IP와 목적 IP를 반대로 지정해서 클라이언트에게 서버 패킷을 통해 전달합니다.

 

단점

비연결성 - 대상 서버의 상태를 확인할 수 없지만 클라이언트는 패킷을 전송합니다. 서버는 패킷을 받을 수 없지만 클라이언트에서는 알 방법이 없습니다. 패킷을 전달 받는 대상이 없을때도 여전히 클라이언트는 패킷을 전달할 수 있습니다.

 

비신뢰성 - 클라이언트에서 서버로 패킷이 전달되는 과정 중에서 패킷은 소실될 수 있고 혹은 여러개의 패킷을 한번에 보낸다면 전달 순서를 보장해주지 않습니다.

 

TCP (Transmission Control Protocol) / IP

전송 제어 프로토콜은 IP Protocol이 가지고 있던 한계를 IP 패킷에 TCP를 더하는 방식으로 해결합니다. TCP는 출발 포트 번호, 목적지 포트 번호, 전송 제어, 순서, 검증 정보등 다양한 정보를 포함하고 있습니다. 연결지향적이고, 데이터 전달을 보증하며, 전달 순서를 보장합니다. 신뢰할 수 있는 프로토콜이지만 UDP보다 전송 속도는 상대적으로 느립니다. TCP는 TCP 3 way handshake라고 하는 가상 연결 방식을 통해서 신뢰성을 보장합니다. 3 way handshake는 처음에 클라이언트에서 SYN이라는 접속 요청을 보내고 다음으로 서버에 연결이 됐다면 서버에서 SYN과 ACK이라는 요청 수락을 보내서 클라이언트에게 데이터를 보내도 좋다고 알려줍니다. 마지막으로 클라이언트는 ACK를 서버에게 보내고 그 이후에 데이터를 전송합니다. 최근에는 최적화가 되어서 마지막 ACK를 보낼때 데이터를 같이 보낼 수 있습니다.

 

UDP(User Datagram Protocol)

사용자 데이터그램 프로토콜은 IP와 비슷하게 동작하지만 포트번호와 체크섬을 포함하는 방식입니다. 데이터 전달 및 순서가 보장되지 않지만 TCP와 달리 3 way handshake와 같은 연결 방식을 채택하지 않았기 때문에 더 빨리 전송할 수 있습니다. 

 

Port

클라이언트에서 한번에 둘 이상의 어플리케이션을 사용한다고 한다면 IP와 다른 또 다른 무언가가 필요합니다. 따라서 이를 포트 번호를 통해 구분하여 사용합니다. 같은 IP내에서 프로세스를 구분할 수 있도록 도와주는 역할을 수행합니다.

 

DNS (Domain Name Server)

IP는 a.b.c.d와 같은형식으로 구성되어 있는데 이를 일일이 기억할 수 없을 뿐더러 IP는 변경 가능하기 때문에 이를 기억해서 접속하기는 어렵습니다. 따라서 클라이언트가 DNS 서버에 특정 사이트의 도메인명을 요청하면 DNS 서버는 그에 맞는 IP를 클라이언트에게 되돌려주고 다시 이 IP 주소를 통해 그 도메인의 서버에 접속할 수 있게 됩니다.

 

HTTP(HyperText Transfer Protocol)

• HTTP/0.9
• HTTP/1.0
• HTTP/1.1 - TCP
• HTTP/2 - TCP
• HTTP/3 - UDP (QUIC) 

특징 

클라이언트는 HTTP 요청 메시지를 통해서 서버에 요청을 보내고 서버는 HTTP 응답 메시지를 통해서 요청에 대한 결과를 만들어서 응답합니다. HTTP는 무상태 프로토콜 (Stateless)를 지향합니다. 이는 서버에서 클라이언트의 정보를 갖고 있지 않아도 되기 때문에 클라이언트 요청이 동시에 많이 발생하거나 서버 장애가 일어나 응답 서버가 바뀌어도 응답에 문제가 생기지 않습니다. 반면에 (Stateful)한 서버에서는 클라이언트의 정보를 다 들고 있기 때문에 서버가 중간에 바뀌며 해당 클라이언트의 요청 정보를 넘겨주지 않는다면 원하는 요청에 대한 응답을 얻을 수 없습니다. 한계 점으로는 로그인과 같은 기능을 구현한다면 서버에 이에 대한 정보를 유지해야 하는데 이러한 경우 브라우저 쿠키와 서버 세션등을 통해 유지하되 상태 유지는 최대한 적게 사용하도록 유지합니다. 또한 HTTP는 비연결성 모델을 추구하는데 이는 서버에서 연결되어 있는 클라이언트의 수를 최대한 적게 유지하도록 도와줍니다. 클라이언트가 사용하지도 않는 연결을 서버에서 계속 이어주고 있다면 서버 자원은 계속 소모됩니다. 따라서 클라이언트가 요청을 보내면 서버는 응답을 주고 연결을 끊어버립니다. 매번 TCP/IP 연결 (3 way handshake)를 새로 만들어야 하기 때문에 시간이 더 걸리고 웹브라우저는 특정 파일만 서버에서 요청을 하지 않고 렌더링에 필요한 수많은 추가 자원들을 요청하기 때문에 새로 계속 연결을 만든다면 비효율적일 수밖에 없습니다. 따라서 HTTP 지속 연결을 통해서 이 문제를 해결합니다.

 

HTTP 메시지

HTTP 메시지는 시작 라인, 헤더, 공백 라인(CRLF, carriage return line feed), 본문으로 이루어져 있습니다. HTTP 요청메시지는 클라이언트가 요청을 보낼때 사용하며, HTTP 응답 메시지는 서버에서 요청에 따른 응답을 만들어서 클라이언트에게 보낼때 사용합니다. 이때 클라이언트에서 서버에 보내는 요청 메시지는 다음과 같은 형식을 가지고 있습니다. 

• 시작 줄 : GET, POST, PUT, DELETE 와 같은 HTTP 요청 메서드, 요청된 리소스를 가리키는 절대 경로, 통신할 HTTP 버전 (예시 : HTTP/1.1)
• 헤더 : General header, Request header, Entitiy header
• 본문 : 모든 요청이 본문을 필요로 하지는 않지만 일부 요청(POST)와 같은 요청은 업데이트를 하기 위해 서버에 데이터를 전송합니다.

서버에서 만들어 클라이언트에게 보내는 HTTP 응답 메시지는 다음과 같은 형식을 가지고 있습니다.

• 상태 줄 : 프로토콜 버전 (앞서 요청에 있던 HTTP 버전과 동일합니다. 예시 HTTP/1.1), 상태 코드 (201, 204), 상태 코드에 대한 짧은 설명(프로그래머가 상태코드에 대해 이해할 수 있도록 사용됩니다.)
• 헤더 : General header, Response header, Entitiy header
• 본문 : 마찬가지로 모든 응답에 본문이 들어가지는 않습니다.

 

HTTP 메서드

• GET : 리소스 조회용 메서드입니다. 서버에 전달하고 싶은 데이터는 쿼리를 통해 전달하고, 메시지 바디(본문)을 사용할 수 있지만 권장하지 않습니다.
• POST : 클라이언트가 메시지 바디를 통해서 서버에게 요청 데이터를 전달해서 처리하도록 하는 메서드입니다. 주로 신규 데이터 등록, 프로세스 처리에 사용합니다.
• PUT : 리소스를 완전히 대체하기 위해 사용하는 메서드입니다. 리소스가 지정된 경로에 존재한다면 대체하고 없다면 생성합니다. POST와 다른 점은 PUT 메서드는 클라이언트가 원하는 요청에 대한 정확한 리소스 위치를 알고 URI를 지정하여 요청을 보내야 합니다. 
• PATCH : 리소스 부분 변경용 메서드입니다. PATCH로 지정된 경로에 요청을 보내면 리소스에 대한 특정 데이터 변경만 요청할 수 있습니다.
• DELETE: 리소스 삭제용 메서드입니다.

 

HTTP 메서드의 속성

https://ko.wikipedia.org/wiki/HTTP

• 안전 (Safe) : 메서드를 호출해도 해당 리소스를 변경하지 않는다. (GET)
• 멱등(Idempotent) : 메서드 호출 횟수와 상관없이 같은 결과를 돌려준다. (GET, PUT, DELETE) 자동 복구 메커니즘에 사용된다. 이는 호출 도중에 다른 클라이언트에 의해 해당 리소스를 변경되는 결과는 신경쓰지 않는다. 간단히 설명하면 서버는 "중간에 누가 다른 요청 메서드 보낸건 모르겠고, 하나의 클라이언트만 요청 보냈을때 원래대로라면 나는 요청된 응답 잘 만들어서 보냈을꺼니까 멱등한거야."라고 우기는거라고 생각하면 된다.
• 캐시가능(Cacheable) : 웹브라우저 내부에 리소스를 저장할 수 있냐 없냐를 묻는 개념이다. 응답 결과를 캐시에 저장하여 다시 요청이 있을때 서버에서 보내는게 아닌 캐시를 통해서 보낼 수 있는 메서드를 캐시 가능이라 한다.

 

HTTP 상태 코드 (HTTP status code)

• 1XX (Informational) : 요청이 수신되어 처리중인 상태를 나타냅니다.
• 2XX (Successful) : 요청 정상 처리
• 3XX (Redirection) : 요청을 완료하려면 추가 작업이 필요한 상태
• 4XX (Client Error) : 클라이언트 오류, 잘못된 요청 등으로 인한 오류
• 5XX (Server Error) : 서버 오류, 서버가 정상 요청을 처리하지 못함

클라이언트가 이해할 수 없는 상태코드를 서버가 응답 메시지에 보내도 클라이언트는 상위 상태코드를 통해서 해석하여 처리합니다. 299라는 상태코드가 들어온다면 클라이언트는 200 정상 처리로 해석하여 인식할 수 있습니다.

https://cheatography.com/kstep/cheat-sheets/http-status-codes/

주로 쓰이는 상태 코드에 대한 설명

• 200 OK - HTTP 메시지에 포함된 메서드에 따른 요청이 성공적으로 수행되었습니다.
• 201 Created - 요청이 성공적이었고 그 결과로 새로운 리소스가 만들어졌습니다.
• 202 Accepted - 요청을 수신하였지만 처리가 완료되지는 않은 상태를 의미합니다. 이는 다른 프로세스에서 처리 또는 서버가 요청을 다루고 있을 수도 있고 배치 작업을 위해 일부로 미뤄둔 상태일 수도 있습니다.
• 204 No Content - 요청에 대해서 보내줄 수 있는 콘텐트가 없지만 헤더는 의미가 있을 수 있습니다. 웹 문서를 저장할때 사용합니다. 
• 300 Multiple Choice - 요청에 대해서 하나 이상의 응답이 가능합니다. 클라이언트는 응답중 하나를 반드시 선택해야합니다. 
• 301 Moved Permanently - 요청한 리소스의 URI가 변경되었음을 의미합니다. 메서드가 GET으로 바뀌고 새로운 URI로 이동되고 본문이 제거 될 수도 있습니다(무조건적이지는 않음).
• 302 Found - 요청한 리소스의 URI가 일시적으로 변경되었음을 의미합니다. 메서드가 GET으로 바뀌고 본문이 제거될 수도 있습니다.
• 303 See Other - 클라이언트가 요청한 리소스를 다른 URI에서 GET 요청을 통해 얻어야 합니다.
• 304 Not Modified - 캐시를 목적으로 사용합니다. 클라이언트에게 리소스가 수정되지 않았음을 알려줍니다. 따라서 클라이언트는 로컬 캐시를 사용하여 리다이렉트합니다. 응답에 본문이 없습니다.
• 307 Temporary Redirect - 302와 동일한 일시적인 리다이렉트지만 요청 메서드와 본문이 유지됩니다.
• 308 Permanent Redirect - 301과 동일하게 URI가 변경되었음을 의미하지만 리다이렉트시 요청 메서드와 본문을 유지합니다.
• 401 Unauthorized - 미승인 (Unauthorized)라고 명시하고 있지만 비인증(Unauthenticated) 된 상태를 의미합니다. 누구인지 확인이 안된 상태를 뜻합니다. 클라이언트는 요청한 응답을 받기 위해서는 반드시 스스로를 인증해야 합니다.
• 403 Forbidden - 클라이언트는 요청한 리소스에 대한 권한이 없기 때문에 응답을 받지 못합니다. 401과 다른 점은 서버는 클라이언트가 누군인지 알고 있지만 권한이 없기 때문에 이러한 오류 코드를 보내는 것입니다.
• 404 Not Found - 요청 리소스가 서버에 없는 상태입니다. 또는 인증받지 않은 클라이언트에게 403 대신에 이 응답을 보낼 수 있습니다.
• 503 Service Available - 서버가 일시적인 과부화 또는 예정된 작업으로 잠시 요청을 처리할 수 없습니다. 이 응답과 함께 문제를 설명하는 페이지가 응답으로 전달이 되어야 합니다. 진짜 서버에 문제가 발생했을 때만 서비스에서 이 응답을 보내는 것이 좋습니다.

 

HTTP 헤더

RFC2616 (과거에 쓰이던 헤더)

• General header : 메시지 전체에 적용되는 정보
• Request heaeder : 요청 정보 
• Response header : 응답 정보
• Entitiy header : 엔티티 바디 정보

RFC7230~7235

• Entity -> Representation (Metadata + Data)
• 표현 헤더 (Content-Type : .....) 는 표현 데이터(json, html)를 해석할 수 있는 정보를 제공한다. 요청과 응답 둘다에 사용된다.
  • Content-Type : 표현 데이터의 형식 - 미디어 타입, 문자 인코딩
  • Content-Encoding : 표현 데이터의 압축 방식 - 표현 데이터를 압축하기 위해서 사용
  • Content-Language : 표현 데이터의 자연 언어 (ko, en)
  • Content-Length : 표현 데이터의 길이 - 바이트 단위, 전송 압축을 사용하면 Content-Length는 사용하면 안됨.
• 협상 헤더 (Content negotiation) - 클라이언트가 원하는 우선순위에 맞춰서 서버에게 선호하는 표현 타입을 요청, 요청시에만 사용된다. 
  
  • Accept : 클라이언트가 선호하는 미디어 타입 전달
  • Accept-Charset : 클라이언트가 선호하는 문자 인코딩
  • Accept-Encoding : 클라이어트가 선호하는 압축 인코딩
  • Accept-Language : 클라이언트가 선호하는 자연 언어 
• 협상과 우선순위 :
  • 우선순위 값(Quality Value)를 통해서 우선순위를 지정해 줄 수 있다.  (Accept-Language : ko-Kr,ko;q=0.9, en-US; q= 0.8, en;q = 0.7) 이 요청에 따라 다중 언어 지원 서버에서는 한국어로 응답하지 못한다면 영어로 응답을 반환한다. 
  • 구체적인 것이 우선한다. Accept : text/, text/html, text/html.... 더 구체적인것에 미디어 타입을 맞춘다.
  • 구체적인 것이 미디어 타입을 결정한다.
• 전송 방식
  • 단순 전송 : 길이를 알고 단순히 요청할 수 있을 때
  • 압축 전송 : 압축 전송 서버에서 해당하는 리소스를 압축하고 Content-Encoding을 통해 압축을 풀 수 있음
  • 분할 전송 : Transfer-Encoding 덩어리를 나누어서 보낼 수 있을 때 사용. 용량이 큰것을 분할해서 바로바로 표시 가능 (Content-Length를 넣으면 안되는 이유는 chunk 마다 길이가 있고 첫 전송시 길이를 예상할  수 없음)
  • 범위 전송 : Content-Range를 통해 범위를 지정하여 전송할 수 있다.
• 정보성 헤더 
  
  • Form  : 유저 에이전트의 이메일 정보 요청에서 사용된다.
  • Referer : 현재 요청된 페이지의 이전 웹 페이지 주소 A -> B로 이동하는 경우 B를 요청할 때 Referer : A를 포함해서 요청 유입 경로 분석시 사용된다. 요청에서 사용
  • User-Agent : 클라이언트의 애플리케이션 정보 (웹 브라우저 정보, 등등) 
  • Server : 요청을 처리하는 origin 서버의 소프트웨어 정보 (응답)
  • Date : 메시지가 발생한 날짜와 시간 (응답)
  • Host : 필수 값 하나의 서버가 여러 도메인을 처리해야 할때 호스트 헤더를 참고해서 거기서 빼서 맞는 도메인을 전달해준다. 
  • Location : 페이지 리다이렉션 : 3XX 응답의 결과에 Location 헤더가 있으면 Location 위치로 자동 이동 (리다이렉트) 
  • Allow : 허용 가능한 HTTP 메서드 : 405에서 응답에 포함해야함 (GET, HEAD, PUT)만 지원한다고 보내야함
  • Retry-After : 유저에이전트가 다음 요청을 하기까지 기다려야 하는 시간.
  • Authorization : 클라이언트 인증 정보를 서버에 전달
  • XXX-Authenticate : 리소스 접근시 필요한 인증 방법 정의 
• 쿠키 : Http는 기본적으로 Stateless 한 상태의 연결을 지향, 따라서 요청과 응답을 만들어서 보낸후에는 연결이 끊김 서버와 클라이언트는 각자에 대한 정보를 가지고 있지 않음. 따라서 쿠키를 사용하지 않고 해결하려면 요청에 사용자 정보를 포함하면됨.. 이러면 모든 요청에 정보를 포함해야 하기 때문에 개발해야하기 때문에 힘들고, 브라우저를 완전히 종료하고 다시 연다면 이런 정보들을 유지하기 더 힘듬. 따라서 쿠키를 사용하여 유저를 쿠키 저장소에 저장해놓고  쿠키 저장소에서 해당 정보를 꺼내온다. 웹 브라우저에서 보내는 모든 요청에 대해 쿠키 저장소에서 정보를 꺼내서 추가해준다. 
  • 사용처 : 사용자 로그인 세션 관리, 광고 정보 트래킹
  • 쿠키 정보는 : 항상 서버에 전송됨 (네트워크 트래픽 추가, 최소한의 정보만 사용, 서버에 전송하지 않고, 웹 브라우저 내부에 데이터를 저장하고 싶으면 웹 스토리지를 만들어야 함)
  • 보안에 민감한 데이터는 쿠키에 저장되면 안된다. (주민번호, 신용카드 번호)
  • 생명 주기 : Set-Cookie를 통해 expires와 max-age를 넣어서 생명주기를 결정할 수 있음. expires는 만료일이 되면 쿠키를 삭제하고 max-age는 0이나 음수를 지정하면 쿠키를 삭제함. 만료 날짜를 생략하면 브라우저 종료시까지만 유지 하고 이를 세션 쿠키라 하고 만료 날짜를 입력하면 해당 날짜까지 유지. 
  • 도메인 : 명시 - 명시한 문서 기준 도메인 + 서브 도메인 포함, 생략 - 현재 문서 기준 도메인만 적용. 
  • 경로 : 해당 경로를 포함한 하위 경로 페이지만 쿠키 접근, 일반적으로 path=/ 루트로 지정
  • 보안 : Secure - 쿠키는 Http, Https를 구분하지 않고 전송, Secure 적용시 https인 경우에만 전송 \ HttpOnly - XSS 공격 방지, 자바스크립트에서 접근 불가(document.cookie), HTTP 전송에만 사용 \ SameSite - XSRF 공격 방지, 요청 도메인과 쿠키에 설정된 도메인이 같은 경우만 쿠키 전송
  • Set-Cookie : 서버에서 클라이언트로 쿠키 전달 (응답)
  • Cookie : 클라이언트가 서버에서 받은 쿠키를 저장하고, HTTP 요청시 서버로 전달.
• 캐시 : 
  • 캐시가 없다면? : 데이터가 변경되지 않아도 계속 네트워크를 통해서 데이터를 다운로드 받아야 한다. 인터넷 네트워크는 매우 느리고 비싸기 때문에 매번 자료를 받아오면 그만큼 비용이 새로든다. 매번 자료를 받아와야 하기 때문에 브라우저 로딩 속도가 느려지고 이에 따라 사용자 경험도 느려진다.
  • 캐시 적용시 헤더를 통해 캐시를 유지할 시간 (cache-control)을 통해서 브라우저 캐시에 저장함. 다시 요청이 있으면 캐시 유효 시간 검증 후 데이터를 받아오지 않고 브라우저 캐시에 저장된 결과를 불러온다. 만약에 캐시 유효 시간 검증 후 시간이 초과되었으면 다시 데이터를 받아오고 캐시 저장소에 있는 데이터를 갱신한다. (네트워크 다운로드가 발생한다)
  • 검증 헤더 : 검증 헤더를 통해 서버상의 데이터가 변화됐는지 추적한다. 만약 수정일 (Last-Modified)를 가지고 있는 캐시가 시간이 만료된 상태이고 서버에서 새로 데이터를 받아오는데 수정일에 차이가 없으면 HTTP 응답 메시지에 304 Not Modified라고 보내고 브라우저에 변경된 데이터가 없음을 알립니다. 데이터가 수정되지 않았기 때문에  이 응답에는 HTTP Body를 포함하지 않습니다. 
  • 조건부 요청 : 캐시가 만료된 데이터를 다시 받아올때 해당 데이터가 데이터 최종 수정일 (Last-Modified)를 포함한다면 조건부 요청(if-modified- since) 을 보낼 수 있다. 이를 통해 서버의 최종 수정일과 비교하여 수정되지 않았다면 웹브라우저 캐시 저장소의 저장되어 있는 데이터를 재활용합니다. 이에  따라 네트워크 다운로드가 수행되지만 최소한으로 수행하여 비용을 아낄 수  있습니다.
  • 캐시 제어 헤더
    • Cache-Control : max-age  캐시 유효 시간, 초 단위
    • Cache-Control : no-cache  데이터는 캐시해도 되지만, 항상 서버에 검증하고 사용. 캐시 무효화 응답
    • Cache-Control : no-store 데이터에 민감한 정보가 있으므로 저장하면 안됨. 캐시 무효화 응답
    • Cache-Control : must-revalidate 캐시 만료 후 최초 조회시 원 서버에 검증해야함. 원 서버에 접근 실패시 반드시 오류가 발생해야함.  (504 Gateway Timeout), must-revalidate는 캐시 유효 시간이라면 캐시를 사용함. 캐시 무효화 응답. (프록시 캐시 서버와 원 서버가 순간적인 네트워크 단절로 연결될 수 없다고 하면 항상 오류 (504 Gateway Timeout)을 응답한다).
    • Cache-Control : public 응답이 public 캐시에 저장되어도 됨
    • Cache-Control : private 응답이 해당 사용자만을 위한 것임
    • Cache-Control : s-maxage 프록시 캐시에만 적용되는 max-age
    • Age : 원 서버에서 응답 후 프록시 캐시 내에 머문 시간 
    • Pragma : no-cache HTTP 1.0 하위 호환용 헤더, 캐시 무효화 응답 
    • Expires 캐시 만료일 지정 (하위 호환)
  • 검증 헤더 (Validator) 
    • Etag (Entity Tag) : 캐시용 데이터에 임의의 고유한 버전이름을 달아둡니다.
    • Last-Modified  : 데이터 변경일을 추적합니다.
  • 조건부 요청헤더
    • If-Modified-Since & If-Unmodified-Since :
      • Last-Modified를 통해 데이터 변경일을 통해 분기 
      • 데이터가 변경되지 않았다면 304 Not Modified, 헤더 데이터만 전송 (Body 미포함) (전송 용량 최소화)
      • 데이터가 변경되었다면 200 OK, 모든 데이터 전송 (BODY 포함)
      • 1초 미만 단위로 캐시 조정이 불가능하다. 날짜 기반의 로직 사용.
    • If-Match & If-None-Match :
      • Etag를 통해 데이터 수정이 있었는지 확인 (Hash)후 분기 
      • 캐시용 데이터에 임의의 고유한 버전 이름을 달아둡니다. 데이터가 변경되면 이 이름을 바꾸어서 변경함 (Hash를 다시 생성) ETag를 보내서 같으면 유지, 다르면 다시 받기 .
      • 캐시 제어 로직을 서버에서 완전히 관리한다. 클라이언트는 이 값을 서버에 제공하는 것으로 캐시 데이터를 갱신할 수 있다.  (클라이언트에서는 캐시 메커니즘을 알고 있지 않아도 된다.)
  • 프록시 캐시 
    
    • 원 서버에서 받아오려면 시간이 더 오래 걸리기 때문에 웹브라우저로 하여금 프록시 캐시 서버를 통해서 프록시 캐시를 가져오도록 함. public한 캐시로 처음 요청이 있으면 다른 클라이언트에게도 다시 그 캐시를 통해서 전달할 수 있음

 

출처

- 모든 개발자를 위한 HTTP 웹 강의

- 면접을 위한 CS 전공지식 노트