인프런 커뮤니티 질문&답변
작성한 질문수 2
순서 정리해봤는데 이게 맞는건가요?
작성
·
61
0
알려주신 내용에 덧붙여서 챗지피티한테도 물어보고 정리해봤습니다
1. 호스트 파일에서 DNS 주소 찾기
2. 없으면 OS & 브라우저의 DNS 캐시 확인
3. 없으면 로컬 DNS 서버(예: ISP DNS) 요청
4. 없으면 상위 DNS 서버 요청 (Root DNS까지 재귀적으로 요청)
5. IP 주소 획득 후 라우팅 수행
6. IP 주소 획득 후 TCP/IP 연결 (3-Way Handshake)
7. 리다이렉트 수행 (필요한 경우)
8. 브라우저 캐시 확인 (304 응답 처리)
9. 프록시 서버 캐싱 확인 (CDN, 로컬 네트워크 캐시)
10. 컨텐츠 다운로드 (HTML, CSS, JS, 이미지 등)
11. 브라우저 렌더링 후 사용자에게 웹사이트 표시
근데 알려주신 강의에는 브라우저 캐싱과 공유 캐싱이 DNS캐시보다 먼저 수행된다고 하니까 어떤게 맞는건지 모르겠네요
답변 2
0
안녕하세요 ㅎㅎ
GPT는 틀린 정보를 제공하기도 합니다.
브라우저 캐싱과 공유 캐싱이 DNS캐시보다 먼저 수행됩니다. 가 맞습니다.
또한 리다이렉트 전에 DNS가 일어나는게 아니라 리다이렉트 -> 캐싱 -> DNS 과정이 일어납니다.
제 강의 자료는 구글 - 크롬개발팀, HTTP2 in action의 저자의 글을 참고했는데요.
아래 글을 참고부탁드립니다.
https://web.dev/articles/ttfb?hl=ko
또 질문 있으시면 언제든지 질문 부탁드립니다.
좋은 수강평과 별점 5점은 제게 큰 힘이 됩니다. :)
감사합니다.
강사 큰돌 올림.
안녕하세요 ㅎㅎ
IP 주소를 획득해야 리다이렉트가 일어나고 IP 주소를 얻기위해 DNS 캐시가 먼저 일어나지 않나 싶은데
-> 맞는 말씀입니다만, 제 강의에서는 TTFB를 기반으로 설명을 드리고 있는데요.
(우리가 어떤 사이트에 들어가서 컨텐츠를 받아올 때의 과정을 설명한다면 TTFB를 기반으로 설명하는게 맞습니다. )
이전 요청에 의해 브라우저가 다른 URL로 리다이렉트된 상태에서 발생한 요청을 기반으로 사용자가 직접 URL 입력 후 최초 요청을 보내는 시점이 아니라, 이전에 이미 브라우저가 특정 URL을 요청하여, 서버가 리다이렉트 응답(3xx)을 줘서 브라우저가 새 URL로 요청을 재시도하는 상태를 나타낸다고 보시면 됩니다.
물론 리다이렉트가 일어나지 않은 상황일수도 있습니다. 그부분을 고려해서 제가 강의내에서 설명을 드릴 때 리다이렉트가 있다면 리다이렉트를 합니다. 라고 설명을 드리고 있습니다.
또한, 이렇게 생각하시면 이해가 더 빠를 수도 있습니다. TTFB에서 리다이렉트 부분을 어디에가다 넣어야 할까? 라고 한다면 가장 앞단에 넣게 될 것 입니다.
공유캐시는 배운대로 프록시서버를 이용하는 거일텐데 프록시서버 ip주소를 모르니 DNS 캐시를 먼저 찾는게 아닌가요?
-> 만약 프록시서버가 도메인으로 되어있다면 DNS 과정을 거치게 됩니다.그러나 대부분의 프록시서버는 IP로 구성이 되어있기 때문에 DNS과정을 거치지 않는다고 보시면 됩니다. (비싼 돈 주고 도메인을 사서 프록시서버에 연결할 일은 거의 없습니다.)
제 생각에는 이부분은 헷갈릴 부분이 있는 소지가 있다 생각합니다. 이부분은 교안내 개선하도록 하겠습니다.
또 질문 있으시면 언제든지 질문 부탁드립니다.
좋은 수강평과 별점 5점은 제게 큰 힘이 됩니다. :)
감사합니다.
강사 큰돌 올림.
답변 감사합니다. 근데 답변에 또 이해가 안가는게 프록시서버에 DNS를 안하고 IP주소만 가지고 있다면 그 아이피 주소를 모를텐데 어떻게 어떻게 접속을 하나요?
만약에 접속을 한다면 프록시 서버가 DNS 정보를 통해 naver의 ip를 가져와서 연결해주는거까지는 이해합니다.
아까 말했듯이 프록시 ip 주소를 어떻게 알아내서 접속하는지 이해가 안갑니다.
안녕하세요 ㅎㅎ
만약 프록시서버가 도메인으로 되어있다면 DNS 과정을 거치게 됩니다.그러나 대부분의 프록시서버는 IP로 구성이 되어있기 때문에 DNS과정을 거치지 않는다고 보시면 됩니다. (비싼 돈 주고 도메인을 사서 프록시서버에 연결할 일은 거의 없습니다.)
-> 제가 수강생님의 질문을 잘못 이해해서 앞의 답변을 한 것 같습니다. 프록시자체의 DNS가 아니라 프록시 캐싱위주로 다시 설명드리겠습니다.
저는 프록시서버에 접속하는 것을 설명하는게 아니라 "캐싱"을 한다는 것을 좀 더 살펴볼 필요가 있습니다.
캐싱이란 최초방문이 아니라 "재방문"했을 때 일어나는 과정입니다.
최초방문과 재방문은 다음의 차이가 있습니다.
최초 방문
클라이언트 → 프록시 서버에 요청
프록시 서버의 DNS -> IP 획득
이후 원본 서버로부터 콘텐츠 받아옴
HTTP 헤더 등을 확인 후, 캐싱 정책에 따라 콘텐츠 저장
클라이언트에게 응답
재방문(짧은 시간 내)
클라이언트가 같은 URL로 재요청
프록시 서버의 DNS 캐시가 여전히 유효하면 DNS 해석을 생략합니다.
이후 캐시에서 바로 콘텐츠 제공 또는 캐시가 만료됐거나 변경되었을 가능성이 있으면 원본 서버와 재검증 후 콘텐츠 갱신
즉, 프록시 서버가 이전에 DNS를 수행했고, 그 결과가 아직 유효하다면 DNS 과정 없이 바로 IP를 사용할 수 있습니다.
또 질문 있으시면 언제든지 질문 부탁드립니다.
좋은 수강평과 별점 5점은 제게 큰 힘이 됩니다. :)
감사합니다.
강사 큰돌 올림.
0
안녕하세요, 인프런 AI 인턴입니다.
wsxqaz789456님께서 질문하신 웹사이트 접속 과정에 대한 순서 정리에 대해 답변 드리겠습니다.
기본적인 웹 사이트 접속 과정에서는 DNS 캐시가 먼저 확인된 후, 콘텐츠 제공 및 사용자에게 표시됩니다. 그러나 DNS 캐시 확인 순서와 캐싱 확인 순서는 다양한 요소와 상황에 따라 달라질 수 있으며, 캐시 메커니즘의 작동 방식이나 로컬 네트워크 설정 등에 따라 차이가 있을 수 있습니다.
TCP/IP 과정과 캐시 확인 순서에 대한 설명을 예로 들어 설명한 글에서는 DNS 캐시가 가장 먼저 확인된다고 설명하는데요, 이는 일반적인 과정입니다:
- 호스트 파일 및 OS/브라우저의 DNS 캐시 확인: 가장 먼저 시스템 차원에서 캐시된 DNS 정보를 확인합니다.
- 로컬 DNS 서버 요청: 캐시에 없을 경우, ISP 등의 로컬 DNS 서버에 요청하여 IP 주소를 확인합니다.
- 상위 DNS 서버 요청: 필요 시, 루트 DNS 서버까지 재귀적으로 요청합니다.
- IP 주소 획득 후 TCP/IP 연결 수행: 일반적으로 IP 라우팅은 IP 주소 획득 직후에 이루어집니다.
- 리다이렉트와 컨텐츠 다운로드: 웹 서버로부터 리소스를 받을 때 캐싱된 자원이 있는지 확인합니다.
순서의 차이는 발생할 수 있으며, 이런 차이점은 각각의 네트워크 환경, 브라우저 혹은 캐시 설정에 따라 발생할 수 있는 변동사항입니다.
추가적으로, 과정 중 리다이렉트와 캐싱에 대한 의문점에서도 비슷한 주제로 다른 학습자의 질문과 강사님이 답변한 내용을 확인하실 수 있습니다.
자세한 내용이나 다른 질문이 있으시다면, 언제든지 추가 질문해 주세요. 강사님께서 자세히 답변해 주실 것입니다.
저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다.
현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏
추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.
답변 감사합니다~
근데 궁금한게 브라우저캐시는 먼저 일어나는게 이해가 가는데 공유캐시는 배운대로 프록시서버를 이용하는 거일텐데 프록시서버 ip주소를 모르니 DNS 캐시를 먼저 찾는게 아닌가요?
그리고 리다이렉트가 예시로 http입력하면 https로 바꾸거나 주소 일부가 바뀌면 제대로 된 주소로 바꿔주는 일로 제가 제대로 이해한거면
이것도 IP 주소를 획득해야 리다이렉트가 일어나고 IP 주소를 얻기위해 DNS 캐시가 먼저 일어나지 않나 싶은데 틀린부분이 궁금합니다