주소의 형태는 크게 URI 와 URL로 구분할 수 있다.
URL | URI |
주소의 구조 중, scheme, host, port, path로 이루어진 주소 스트링값을 말한다 | URL의 구조에서 query, bookmark를 포함한 구조를 말한다. |
이때, 캐싱 기록을 찾는 순서는 브라우저 -> OS -> Router -> ISP 순으로 이루어진다.
캐싱을 사용하는 이유는 DB에 지속적으로 I/O가 발생하는 경우 너무 비싼 비용이 들기 때문에 순수하게 정적 데이터를 제공하는데에 특화된 저장소에서 필요한 데이터를 빠르게 가져오도록 하는 것이다.
Router = OSI7계층에서 3번째 계층에 해당하는 영역으로, data를 ip 패킷으로 감싼 후 이 패킷을 어떻게 최적화된 루트를 통해서 전달해줄지를 결정해주는 역할을 한다.
ISP = Internet service provider의 약자로, 인터넷 서비스를 제공하는 회사를 칭한다 (ex, KT). 즉, 이 회사의 캐시데이터에서 도메인 네임을 찾는것
예를들어, test.google.com이라는 도메인 네임을 찾기 시작한다면
"." 서버에서 com을 찾음 => ".com" 서버에서 google.com 서버를 찾음 => google.com서버에서 test.google.com을 찾음
이렇게 마지막 서버에서 찾아낸 ip 주소를 recursive하게 찾은 후, 이 내용을 브라우저에게 전송한다.
OSI 4계층에 해당하는 내용으로, ip 패킷의 문제점을 보안하기 위한 후속조치이다.
ip 패킷의 문제점은 크게 2가지로 나뉜다
Connectionless
설령 데이터를 받을 대상이 없더라도 패킷이 무조건 전송된다
Unreliable
네트워크 장애로 중간에 데이터가 소실되더라도 이를 알아차릴 방법이 없다
또한, 데이터가 너무 커서 청크단위로 나누어 패킷으로 감싸고 전달했을 경우, 해당 패킷들의 결합순서가 보장되지 않는다.
이 때문에 해당 단점들을 보안할 방법으로 TCP 계층이 추가된다
TCP 연결은 우선 서버와의 3 handshake를 이용하여 SYN(synchronize), ACK(acknowledge) 를 거친다
(만약, https 연결이 필요하다면 이 과정에서 비대칭 키와 인증서를 이용한 공유키 공유과정을 한번 더 거친다.)
해당 요청을 통해 필요한 파일들(html 등) 을 서버로부터 받는다.
이때 요청 객체의 헤더부분에 존재하는 내용들을 통해서 네트워크 응답간의 옵션들을 설정해줄 수 있다.
예를들어, Connection 헤더의 경우 서로간의 연결을 계속 유지해줄지 말지를 결정해주는 헤더이다
헤더는 크게 3가지 영역으로 나뉜다
-general header = 통신에 대한 옵션들을 나타내는 헤더 (ex Connection)
-request || response header = 응답을 주고받을 때에 자신들이 어떤 형태로 받아들일지에 대한 옵션들을 설정한 부분 (ex Accept)
-representation header = 만약 body에 데이터가 존재할 경우, 이 body에 대한 내용을 설정하는 부분
요청 예시