DNS와 자원
클라 -> 서버는 요청 메시지 송신, 서버 -> 클라 응답 메시지 송신
이 요청 - 응답 메시지 송수신 과정 덕분에 브라우저에 특정 URL을 통해 접근할 수 있는 것.
우리는 IP를 외워서 쓰지 않는다. 도메인 네임만 알아도 다 거기로 연결되고, IP는 바뀔 수 있기 때문. 도메인 네임은 호스트의 IP 주소와 대응되는 문자열 형태의 호스트 특정 정보.
URL - 위치 기반 식별자, URN - 이름 기반 식별자
도메인과 네임 서버
도메인 네임과 IP 주소는 네임 서버에서 관리한다. 이 서버를 DNS 서버라고 부르기도 한다. 네임 서버는 전화번호부 같은 역할. 이를 위해 DNS를 사용한다.
루트 도메인 - 도메인 네임의 맨 끝에 점을 찍는 형태로 표기된다.
naver.com. <- 이렇게 쓰는건데 생략할 수 있다.
최상위 도메인(TLD) - .com, .net, .org, .kr
도메인은 점을 기준으로 계층 구조를 이루고 있다. 그리고 네임서버도 도메인 네임의 관리를 위해 계층 형태를 이룬다.
계층적 네임 서버
IP주소를 모르는 상태에서 도메인 네임에 대응되는 IP 주소를 알아내는 과정을 도메인 네임을 풀이(resolve)한다고 한다.
로컬, 루트, TLD, 책임 등의 도메인 네임 존재
로컬 - 클라이언트가 도메인 네임을 통해 IP를 알아내고자 할때 가장 먼저 찾게 되는 네임 서버
-> 클라가 로컬 네임서버에게 IP를 물었을 때 알면 알려주면 된다
-> 근데 로컬이 모르면 루트 네임서버에게 물어본다.
-> 루트도 모르면 TLD 네임서버에게 물어본다.
-> TLD도 몰?루 하고 다음 레벨에다 물어보면 마침내 끝판왕인 책임 DNS 서버가 응답을 준다
이렇게 응답이 오면 앞 과정을 역순으로 돌아 응답을 전해준다
이 과정을 재귀적 질의 라고 한다.
- 이것의 문제 - 전 세계 모든 사람이 루트 네임 서버에 질의하면 루트 네임서버에 과부하가 걸림🤯🤯🤯
그래서 한번 얻어놓은 DNS를 어딘가에 잠깐 저장해놓고 필요할 때 꺼내서 재활용함. 그게 바로DNS 캐시임.
-
브라우저 캐시
방금 다녀온 사이트 주소를 또 묻지 않도록 브라우저가 도메인의 IP 주소를 자체 캐시에 저장하는 것. -
운영체제(OS) 캐시
브라우저 캐시에 IP주소가 없다면 운영체제의 DNS 캐시를 조회함. OS도 최근에 조회된 IP 주소를 일정 기간 캐시에 저장하기 때문! -
라우터 캐시
OS 캐시에서도 IP 주소를 찾을 수 없으면 네트워크 라우터로 요청이 넘어간다. 라우터들은 대부분 자체적으로 DNS 캐시를 관리하기 때문. -
ISP 캐시
라우터에서도 IP 주소를 못 찾으면 DNS 조회는 ISP의 DNS 서버로 넘어간다. ISP는 대규모의 DNS 서버를 운영하고 많은 도메인의 IP 주소를 캐시에 저장해두기 때문. -
위의 그 어느 캐시애도 DNS가 없는 경우 - 재귀적 DNS 조회
이제는 더이상 갈 곳이 없으므로 루트 네임서버부터 TDL 책임까지 다시 재귀적으로 물어봐야 한다.(으으 귀찮아)
-> 이렇게 해서 드디어 IP를 찾으면 그 IP가 브라우저로 전달되고 각 단계의 캐시도 업데이트 된다!
TTL - Time To Live
참고 블로그
네트워크에서 데이터의 유효기간을 나타내기 위한 방법 - 라우터에서 라우터로 무한정 전달되는 것을 막기 위해.
- TTL이 설정되지 않는다면 목적지를 찾지 못한 패킷이 영원히 네트워크에 잔류하게 된다!
네트워크의 망령- TTL 설정 시 - TTL은 라우터와 같은 네트워크 장비를 거칠 때 마다 값이 1씩 감소 -> TTL이 0이 되면 패킷 드랍!
패킷을 놓아주었다. 바이바이 패킷! 이 된다.
자원을 식별하는 URI
URL하고는 다른게, URI는 식별할 수 있는 모든 정보를 말한다. URL은 URI 중 위치로 식별하는 것을 말한다.
자원은 네트워크 상의 메세지를 통해 주고받는 대상을 말한다. 뭔소리야? 싶으면 '리소스' 라고 부르자. 이건 HTML, 동영상, 텍스트 뭐든 될 수 있다. 우리가 하는 카톡도 다 자원인 셈.
이걸 왜 식별해야 하냐면, 식별을 해야 네트워크 상에서 주고받을 수 있다. 이 자원을 식별할 수 있는 정보를 URI 라고 한다.
그러면 URI는 무엇을 통해 자원을 식별할까? 위치일 수도, 이름일 수도 있다. 이 중 위치로 식별하는 게 우리가 아는 URL이다.
scheme / domain name / port / path / param / anchor 로 구분된다.
scheme - 자원에 접근하는 방법
domain name - authority. 호스트를 특정할 수 있는 정보
port - IP 혹은 도메인 네임에 특정한 호스트를 지정하기 위해 사용
/over/there/ - 자원이 위치한 경로가 명시됨. 자원의 위치는 슬래시를 기준으로 계층적으로 표현
query - HTTP는 응답-요청 기반의 프로토콜. 지금까지의 URL보다 많은 정보가 필요해서 scheme, path만으로 표현 못 할 수도 있음. 그때 쓰는게 query. 물음표로 시작되는 <key-value> 형태 데이터로, &를 이용해 여러 쿼리 문자열 연결 가능.
#rtan - fragment 라고 함.
URN - 이름 기반 식별자
urn:isbn:04500000 (ISBN = 서적)
이런 식으로 사용하면 위치나 프로토콜과 무관하게 이름으로 찾을 수 있다. 위치는 변할 수 있기 때문이라는 취지인데 그렇게 널리 쓰이진 않는다.
HTTP - Stateless!
HTTP는 상태를 유지하지 않는 프로토콜이다. 이 예시를 기억하는가?
철수: 늘 먹던걸로
가게: 롸? 누구세요?
상태를 유지하지 않는 특성은 장점이 명확. HTTP 서버는 일반적으로 많은 요청이 들어오기 때문에 수백만일 수 있다. 모든 클라이언트의 상태 정보를 유지하는 것은 서버 부담이 너무 크다.
또한 서버는 여러대일 수 있다. 이런 상황에서 모든 서버가 모든 클라이언트와의 상태를 유지하고 저장할 수는 없다. 모든 서버가 클라이언트의 상태를 공유하는 것은 몹시 어렵기 때문.
HTTP는 TCP 기반의 프로토콜이다.
-
클라이언트의 요청이 없음에도 서버가 응답을 주려면 웹소켓이 필요함! 이래서 우리가 웹소켓을 배우는 것. 게임은 항상 유저가 뭔갈 해야만 반응하는 게 아니다. 유저가 아무것도 안해도 서버는 정보를 뿌려줘야 할 수 있기 때문!
-
비연결성 - 알다시피 요청을 주고받을 때만 연경을 유지한다.
단점 - 요청 주고 받을때마다 악수 세번씩 해야한다 (3-way-handshaking)
장점 - 서버의 자원을 효율적으로 사용할 수 있다
