이 기사에서는 브라우저에 관한 몇 가지 인터뷰 질문을 공유할 것입니다. 당신이 대답할 수 있는 질문은 몇 가지입니까? 정답을 분석하고 몇 개나 맞힐 수 있는지 확인해 보세요!
1. 일반적인 브라우저 커널은 무엇입니까?
브라우저 커널은 두 부분으로 나눌 수 있습니다:
渲染引擎和JS引擎 (참고: 우리가 자주 참조하는 브라우저 커널은 렌더링 엔진을 의미합니다)
JS 엔진이 점점 더 발전하고 있기 때문에 독립적으로, 커널은 단지 렌더링 엔진을 의미하며 렌더링 엔진은 주로 네트워크 페이지 리소스를 구문 분석하고 조판하여 사용자에게 표시하도록 요청하는 데 사용됩니다
Browser/RunTime
Kernel(렌더링 엔진)
JavaScript 엔진
Chrome
Blink(28~) 웹킷(Chrome 27)
V8
FireFox
Gecko
SpiderMonkey
S afari
Webkit
JavaScriptCore
Edge
EdgeHTML
Chakra(JavaScript용)
IE
Trident
Chakra(JScript용)
Opera
Presto->blink
Linear A(4.0-6.1)/Line 아르 B(7.0 -9.2)/Futhark(9.5-10.2)/Carakan(10.5-)
Node.js
-
V8
2. 브라우저의 주요 구성요소는 무엇인가요?
사용자 인터페이스: 주소 표시줄, 앞으로/뒤로/새로 고침/북마크 버튼 등 포함
브라우저 엔진: 사용자 인터페이스와 렌더링 엔진 간에 명령을 전송합니다.
렌더링 엔진: 요청을 그리는 데 사용됩니다.
네트워크: http 요청과 같은 네트워크 호출을 완료하는 데 사용되며 플랫폼 독립적인 인터페이스를 가지며 다양한 플랫폼에서 작동할 수 있습니다.
JavaScript 인터프리터: JavaScript 코드를 구문 분석하고 실행하는 데 사용됩니다
사용자 인터페이스 백엔드: 콤보박스, 윈도우 등 기본 위젯을 그리는 데 사용됩니다. 하단 레이어는 운영체제의 사용자 인터페이스를 사용합니다
데이터 저장: 브라우저는 쿠키와 같은 다양한 데이터를 하드에 저장합니다. disk, HTML5는 가볍고 완전한 클라이언트측 저장 기술인 웹 데이터베이스 기술을 정의합니다
참고: 대부분의 브라우저와 달리 Google(Chrome) 브라우저의 각 탭은 각각 렌더링 엔진 인스턴스에 해당합니다. 각 탭은 독립적인 프로세스입니다
3. URL을 입력하면 페이지 렌더링이 어떻게 되는지 알려주세요.
이 질문은 면접에서 가장 많이 나오는 질문이라고 할 수 있고, 한없이 어려울 수 있습니다. 일반적으로 면접관들은 프론트엔드 지식의 깊이를 테스트하기 위해 이 질문을 합니다.
1. 브라우저는 URL을 수락하고 네트워크 요청 스레드를 엽니다(포함: 브라우저 메커니즘, 스레드 및 프로세스 등)
2 네트워크 스레드를 열고 완전한 http 요청을 발행합니다(포함: DNS 쿼리, TCP /IP 요청, 5계층 네트워크 프로토콜 등)
3. 서버에서 해당 백엔드로의 요청을 수신합니다. (관련: 로드 밸런싱, 보안 차단, 백엔드 내부 처리 등)
4. 백엔드 및 프런트엔드(대상: http 헤더, 응답 코드, 메시지 구조, 쿠키 등 포함)
5. 캐시 문제(관련: http 강력한 캐시 및 협상된 캐시, 캐시 헤더, etag, 만료, 캐시 제어, 등)
6. 브라우저 http 패킷을 수신한 후 구문 분석 프로세스(HTML 어휘 분석 포함, DOM 트리로 구문 분석, CSS를 구문 분석하여 CSSOM 트리 생성, 병합하여 렌더링 트리 생성) 복합 레이어 합성, GPU 드로잉, 외부 링크 처리 등)
7. CSS 시각적 모델(포함: 요소 렌더링 규칙, 예: 포함 블록, 컨트롤 박스, IFC 등)
8. 파싱 프로세스(포함: JS 파싱 단계, 전처리 단계, 실행 단계는 실행 컨텍스트, VO(전역 객체), 범위 체인, 재활용 메커니즘 등을 생성합니다.) 입력 URL과 페이지 렌더링이 즉시 중단되었다고 느끼십니까? (걱정하지 마세요. 이 장에서는 이에 대해 자세히 다루지 않습니다. 먼저 이 질문에 대답하는 방법을 가르쳐 드리겠습니다. 나중에 별도의 기사에서 다룹니다.)
브라우저는 DNS 서버를 통해 도메인 이름의 IP 주소를 가져오고 이 IP 주소로 요청을 보냅니다. HTML 텍스트를 가져오기 위한 요청
브라우저 렌더링 프로세스는 HTML 텍스트를 구문 분석하고 DOM 트리를 구축합니다
HTML을 구문 분석하는 동안 인라인 스타일이나 스타일 파일을 발견하면 스타일 규칙을 다운로드하고 JavaScript 스크립트를 발견하면 DOM을 실행합니다. 트리와 CSSOM이 구성되면 렌더링 프로세스는 둘을 렌더 트리로 병합합니다.
렌더링 프로세스는 렌더링 트리를 레이아웃하고 레이아웃 트리를 생성하기 시작합니다.
렌더 트리 대 레이아웃 트리 그리기 수행 및 그리기 기록 생성
4. 브라우저는 코드를 어떻게 구문 분석하나요?
Parse HTML
HTML은 한 줄씩 구문 분석되며, 브라우저의 렌더링 엔진은 HTML 문서를 구문 분석하고 DOM 노드로 변환합니다. HTML을 여러 토큰으로 구문 분석
토큰을 객체로 구문 분석
객체를 DOM 트리로 결합
CSS 구문 분석
브라우저는 CSS 선택기를 오른쪽에서 왼쪽으로 구문 분석합니다
그거 알아 DOM 트리와 CSSOM 트리는 렌더링 트리에 병합되어 실제로 CSSOM을 DOM 트리에 연결하므로 선택기가 제공하는 정보를 기반으로 DOM 트리를 탐색해야 합니다.
오른쪽에서 왼쪽으로 일치: 먼저 가장 오른쪽에 있는 노드 범위를 모두 찾고, 각 범위에 대해 위쪽으로 노드 div.title
을 검색합니다. 그런 다음 위쪽으로 div.nav의 노드
가 마침내 루트 요소 html을 찾으면 이 분기의 순회가 종료됩니다.
Parse JS
브라우저에는 js 코드를 파싱하는 데 특별히 사용되는 js 파서 도구가 있습니다. 브라우저가 js 코드를 발견하면 즉시 "js 파서"를 호출하여 작동합니다.
파서는 js에서 모든 변수, 함수, 매개변수 등을 찾아 해당 변수 값을 정의되지 않음으로 할당합니다.
기능을 펑션블록에 꺼내어 창고에 보관하세요. 이 작업이 완료되면 코드는 한 줄씩(위에서 아래로, 왼쪽에서 오른쪽으로) 구문 분석되기 시작하고 창고와 일치됩니다.
5.DOMContentLoaded와 로드의 차이점은 무엇인가요?
DOMContentLoaded: 스타일 시트, 이미지 및 기타 리소스를 제외하고 DOM 구문 분석이 완료된 후에만 트리거됩니다.
로드: 페이지의 모든 DOM, 스타일 시트, 스크립트, 이미지 및 기타 리소스가 로드되면 트리거됩니다.
6. 브라우저 다시 그리기와 도메인 재배치의 차이점은 무엇인가요?
재배열: 렌더링 트리의 일부 또는 전체 렌더링 트리를 다시 분석하고 노드 크기를 다시 계산해야 하며, 이는 레이아웃을 재생성하고 요소를 재배열하는 것으로 나타납니다.
다시 그리기: 노드의 기하학적 속성 또는 스타일 요소 배경 요소와 같은 변경 사항은 특정 요소의 모양이 변경되는 것으로 나타납니다.
다시 그리는 것이 반드시 리플로우로 이어지는 것은 아니지만 다시 그리면 확실히 다시 그리기로 이어집니다
방법 다시 그리기 및 리플로우를 트리거합니까?
렌더 트리를 구축하는 데 사용된 정보를 변경하면 리플로우 또는 다시 그리기가 발생합니다.
DOM 노드 추가, 삭제, 업데이트
디스플레이를 통해 DOM 노드 숨기기: 없음 - 리플로우 및 다시 그리기 트리거
가시성을 통해 DOM 노드 숨기기: 숨김 - 기하학적 변경 사항이 없으므로 다시 그리기만 트리거합니다.
페이지에서 DOM 노드를 이동하거나 애니메이션화합니다.
스타일시트 추가 및 스타일 속성 조정
창 크기 조정과 같은 사용자 동작, 글꼴 크기를 변경하거나 스크롤합니다.
다시 그리거나 리플로우하는 것을 방지하는 방법은 무엇입니까?
스타일 집중 변경: 예를 들어 클래스를 사용하여 스타일을 일괄적으로 변경합니다.
document.createDocumentFragment() 사용: DOM 트리에서 자유로운 문서를 생성할 수 있습니다. createDocumentFragment 노드를 통해 이 노드에서 일괄 작업이 수행되고 마지막으로 DOM 트리에 삽입되므로 한 번의 리플로우만 트리거됩니다. document.createDocumentFragment()：我们可以通过createDocumentFragment创建一个游离于DOM树之外的节点，然后在此节点上批量操作，最后插入DOM树中，因此只触发一次重排
다시 칠하기</code할 때 >가 필요하며 <code>다시 그리기 자체만 다른 레이어에 영향을 주지 않습니다
변형 및 불투명도 효과의 경우 레이아웃</ code> 및 <code will not be Triggered >paint
컴포지션 레이어를 향상하는 가장 좋은 방법은 CSS will-change 속성
7. JS는 왜 단일 스레드인가요?
이것은 주로 JS의 목적과 관련이 있습니다. 브라우저의 스크립트 언어로서 JS는 처음에는 사용자와 브라우저 간의 상호 작용을 구현하고 DOM을 운영하는 데 주로 사용되었습니다. 이는 단일 스레드만 가능하다는 것을 결정합니다. 그렇지 않으면 많은 복잡한 동기화 문제가 발생합니다. 예: JS가 다중 스레드인 경우 한 스레드는 DOM 요소를 수정하려고 하고 다른 스레드는 DOM 요소를 삭제하려고 하면 브라우저는 누구의 말을 들어야 할지 알 수 없습니다. 따라서 복잡성을 피하기 위해 JavaScript는 처음부터 단일 스레드로 설계되었습니다.
🎜🎜멀티 코어 CPU의 컴퓨팅 성능을 활용하기 위해 HTML5는 JavaScript 스크립트가 여러 스레드를 생성할 수 있도록 허용하지만 하위 스레드는 메인 스레드에 의해 완전히 제어되며 스레드를 작동해서는 안 되는 Web Worker 표준을 제안합니다. DOM. 따라서 이 새로운 표준은 JavaScript🎜🎜
의 단일 스레드 특성을 변경하지 않습니다. 8. CSS 로딩이 DOM을 차단합니까? 🎜🎜🎜🎜먼저 결론🎜🎜🎜
🎜🎜CSS는 DOM의 구문 분석을 차단하지 않지만 DOM<의 렌더링은 차단합니다. /code> 🎜🎜<code>CSS는 JS의 실행을 차단하지만 JS 파일🎜🎜
🎜의 다운로드는 차단하지 않습니다. 🎜🎜CSSOM의 역할🎜 🎜🎜🎜🎜🎜첫 번째는 JavaScript에 스타일 시트를 조작할 수 있는 기능을 제공하는 것입니다.🎜🎜🎜🎜두 번째는 레이아웃 트리 합성을 위한 기본 스타일 정보를 제공하는 것입니다🎜🎜🎜🎜이 CSSOM은 DOM에 document .styleSheets🎜🎜🎜🎜로 반영됨 앞서 언급한 브라우저 렌더링 프로세스에서 볼 수 있습니다. 🎜🎜🎜🎜DOM과 CSSOM은 일반적으로 병렬로 구축되므로 🎜CSS 로딩이 차단되지 않습니다. DOM 구문 분석🎜🎜🎜 🎜🎜렌더 트리는 DOM 트리와 CSSOM 트리에 따라 다르므로 둘 다 로드될 때까지 기다려야 렌더링 작성을 시작할 수 있으므로 🎜CSS 로드로 인해 DOM 렌더링이 차단됩니다🎜🎜🎜🎜🎜 JavaScript는 DOM과 CSS를 동작시킬 수 있기 때문에, 이들 요소의 속성을 수정하면서 인터페이스를 렌더링한다면(즉, JavaScript 스레드와 UI 스레드가 동시에 수행되는 경우), 렌더링 스레드 이전과 이후에 얻은 요소는 다음과 같을 수 있습니다. 일관성 없는. 따라서 예상치 못한 렌더링 결과를 방지하기 위해 브라우저는 🎜GUI 렌더링 스레드와 JavaScript 스레드를 상호 배타적으로 설정합니다🎜🎜🎜🎜🎜🎜🎜JS는 CSS 다운로드를 기다려야 합니다. 이유는 무엇입니까? (CSS는 DOM 실행을 차단합니다)🎜🎜🎜
JS 스크립트의 내용이 요소의 스타일을 가져오는 것이라면 CSS를 사용해야 합니다. 브라우저는 JS 내부에서 무슨 일이 일어나고 있는지 감지할 수 없기 때문에 스타일 획득을 피하기 위해 JS를 실행하기 전에 이전 스타일이 모두 다운로드될 때까지 기다려야 합니다. 단, JS 파일과 CSS 파일은 병렬로 다운로드되어 후속 JS 파일이 실행되기 전에 CSS 파일이 로드되어 실행되므로 JS脚本的内容是获取元素的样式，那它就必然依赖CSS。因为浏览器无法感知JS内部到底想干什么，为避免样式获取，就只好等前面所有的样式下载完毕再执行JS。但JS文件与CSS文件下载是并行的，CSS文件会在后面的JS文件执行前先加载执行完毕，所以CSS会阻塞后面JS的执行
defer是在JS加载完成后，整个文档解析完成后，触发 DOMContentLoaded 事件前执行，如果缺少 srcCSS는 후속 JS 실행을 차단
화이트 스크린을 방지하고 개선합니다. CSS 로딩 속도
CDN 사용(CDN은 캐시된 콘텐츠가 있는 가장 가까운 노드를 선택하여 네트워크 상태에 따라 리소스를 제공하므로 로딩 시간을 줄일 수 있습니다.) CSS 압축 캐시를 합리적으로 사용
http 요청 수 감소, CSS 파일 병합
9. JS가 페이지를 차단합니까?
먼저 결론을 내리자
JS는 DOM 파싱을 차단
하므로 페이지 로딩을 차단하게 됩니다
이래서 JS 파일을 맨 밑에 넣어야 한다는 이야기를 자주 하는 이유입니다.
JavaScript는 DOM을 조작할 수 있으므로 인터페이스를 렌더링하는 동안 이러한 요소의 속성을 수정하면(즉, JavaScript 스레드와 UI 스레드가 동시에 실행됨) 렌더링 스레드 전후에 얻은 요소 데이터가 일관성이 없을 수 있습니다.
따라서 예상치 못한 렌더링 결과를 방지하기 위해 브라우저는 **"GUI 렌더링 스레드와 JavaScript 엔진은 상호 배타적입니다"** 관계를 설정합니다.
JavaScript 엔진이 실행되면 GUI 스레드가 일시 중지되고 GUI 업데이트가 대기열에 저장되어 엔진 스레드가 유휴 상태가 되면 즉시 실행됩니다.
브라우저가 JavaScript 프로그램을 실행할 때 GUI 렌더링 스레드는 대기열에 저장되며 JS 프로그램이 완료될 때까지 실행되지 않습니다.
그래서 JS의 실행 시간이 너무 길면 페이지 렌더링이 일관되지 않아 페이지 렌더링 및 로딩이 차단되는 느낌을 받게 됩니다.
10. 지연과 비동기의 차이점은 무엇인가요?
둘 다 외부 JS 파일을 비동기식으로 로드하며 DOM 구문 분석을 차단하지 않습니다.
Async는 외부 JS 로드가 완료된 후, 브라우저가 유휴 상태일 때, Load 이벤트가 트리거되기 전에 실행됩니다. 실행되는 순서를 지정하십시오. 이 속성은 인라인 스크립트(즉, "src" 속성이 없는 스크립트)에는 영향을 미치지 않습니다.
defer는 JS가 로드된 후, 전체 문서가 구문 분석된 후, src 속성(예: 내장된 스크립트)이 트리거되기 전에 실행됩니다. 누락된 경우 이 속성은 작동하지 않으므로 사용하면 안 됩니다.
11. 브라우저의 가비지 수집 메커니즘
가비지 수집은 자동 메모리 관리 메커니즘입니다. 컴퓨터의 동적 메모리는 더 이상 필요하지 않을 때 해제되어야 합니다.
자동이란 브라우저가 자동으로 메모리 쓰레기를 재활용하는 데 도움을 줄 수 있다는 의미이지만, 메모리 관리에 신경 쓸 필요가 없다는 의미는 아닙니다. 제대로 작동하지 않으면 JavaScript에서 메모리 오버플로가 계속 발생합니다. , 시스템 충돌을 일으킵니다. 🎜🎜🎜문자열, 배열, 객체 등은 고정된 크기가 없으므로 크기가 알려지면 동적으로 할당해야 합니다. JavaScript 프로그램이 문자열, 배열 또는 객체를 생성할 때마다 인터프리터는 해당 엔터티를 저장하기 위해 메모리를 할당해야 합니다. 🎜🎜JavaScript 해석기는 프로그램이 더 이상 객체를 사용하지 않는 시기를 감지할 수 있습니다. 객체가 쓸모없다고 판단되면 객체가 더 이상 필요하지 않다는 것을 알고 객체가 차지하는 메모리를 해제할 수 있습니다. 🎜🎜브라우저에서 일반적으로 사용하는 가비지 수집 방법에는 🎜마크 스윕🎜, 🎜참조 카운팅🎜이라는 두 가지 방법이 있습니다. 🎜🎜🎜🎜마크 지우기🎜🎜🎜🎜🎜이것은 JavaScript에서 가장 일반적으로 사용되는 가비지 수집 방법입니다.🎜🎜🎜2012년 이후 모든 최신 브라우저는 하위 버전의 IE 참조 카운팅을 제외하고 마크 지우기 가비지 수집 방법을 사용했습니다. 🎜🎜🎜그럼 마크제거란 무엇일까요? 🎜🎜🎜🎜JavaScript에는 전역 개체가 있습니다. 주기적으로 가비지 수집기는 이 전역 개체에서 시작하여 이 전역 개체에서 참조되는 모든 개체를 찾은 다음 이러한 개체가 참조하는 개체를 찾습니다. 이러한 활성 개체의 경우 마킹, 마킹 단계입니다. 지우기 단계는 표시되지 않은 개체를 지우는 것입니다. 🎜🎜🎜마크 클리어의 문제점은 클리어 후 메모리 공간이 불연속적, 즉 메모리 조각화가 발생한다는 것입니다. 나중에 상대적으로 큰 연속 메모리 공간이 필요할 경우 요구 사항을 충족하지 못합니다. 🎜마크 정리🎜 방법은 이 문제를 효과적으로 해결할 수 있습니다. 🎜🎜마킹 과정에서 3색 마킹 개념이 도입되었습니다. 3가지 색상은 🎜🎜🎜흰색: 표시되지 않은 개체, 즉 도달할 수 없는 개체(스캔되지 않은 개체)를 재활용할 수 있습니다. 🎜🎜회색. : 표시가 된 개체(접근 가능한 개체)이지만 아직 검사되지 않아 재활용할 수 없는 개체 🎜🎜검은색: 검사된(접근 가능한 개체)이며 재활용할 수 없는 개체 🎜🎜🎜🎜 표시 정렬: 🎜🎜
마킹 단계는 마킹이 완료된 후 살아남은 개체를 메모리의 한쪽으로 이동하고 마지막으로 경계 메모리를 정리한다는 점을 제외하면 마크 앤 클리어 방법과 다르지 않습니다.
참조 카운팅
참조 카운팅의 의미는 각 값이 참조되는 횟수를 추적하는 것입니다. 변수 A에 값이 할당되면 이 값에 대한 참조 수는 1입니다. 변수 A가 다시 할당되면 이전 값에 대한 참조 수가 1씩 줄어듭니다. 참조 개수가 0이 되면 더 이상 이 값에 접근할 수 없다는 뜻이므로 이 값이 차지하는 메모리를 지울 수 있다.
대부분의 브라우저는 이 재활용 방법을 포기했습니다.
메모리 누수
메모리 누수를 방지하려면 데이터가 더 이상 사용되지 않으면 해당 값을 null로 설정하는 것이 가장 좋습니다. code>참조를 해제하려면 이 방법을 null来释放其引用，这个方法叫做接触引用
클로저에 있는 경우 클로저에 참조가 없을 때까지 V8에서 재활용되지 않습니다. 🎜🎜비밀폐형의 경우 V8의 차세대 스위치를 기다리며 재활용됩니다. 🎜🎜🎜🎜
12. 브라우저의 캐싱 메커니즘에 대해 알려주세요.
🎜🎜🎜브라우저 캐시 이해하기🎜🎜🎜🎜브라우저가 웹사이트를 요청할 때 다양한 리소스를 로드합니다. 자주 변경되지 않는 일부 리소스의 경우 브라우저는 다음 번에 이를 위해 로컬 메모리에 저장합니다. 액세스 속도를 향상시키기 위해 액세스 중에 직접. 🎜🎜🎜🎜리소스가 서버에서 요청되었는지 아니면 캐시에서 읽혀졌는지 어떻게 알 수 있나요? 🎜🎜🎜🎜🎜 🎜위 그림을 보세요. 일부 리소스의 크기 값은 디스크 캐시에서이고, 일부는 메모리 캐시에서입니다. 요청된 서버 리소스 중 두 개는 읽기 캐시로 표시됩니다. 🎜
🎜🎜디스크 캐시: 🎜 디스크에 리소스를 저장하고 다시 다운로드하지 않고 다음 액세스를 기다리는 것입니다. 디스크에서 직접 읽을 수 있습니다. CurlCacheManager . (메모리캐시에 비해 효율은 느리지만 저장용량이 크고 저장시간이 길다) 🎜🎜🎜메모리캐시 : 🎜 메모리에 자원을 캐싱하고, 재다운로드 없이 다음 접근을 기다리는 것이며, 메모리에서 직접 읽기. (효율성 측면에서 가장 빠르며, 생존 시점 측면에서 가장 짧습니다.) 🎜🎜🎜🎜🎜🎜-🎜🎜메모리 캐시🎜🎜디스크 캐시🎜🎜🎜🎜🎜🎜동일 포인트🎜🎜 가능 일부 파생 리소스 파일만 저장🎜🎜일부 파생 리소스 파일만 저장할 수 있습니다🎜🎜🎜🎜차이점🎜🎜프로세스를 종료하면 데이터가 지워집니다🎜🎜프로세스를 종료해도 데이터는 지워지지 않습니다🎜🎜🎜🎜저장 resources🎜🎜일반 스크립트, 글꼴, 그림은 메모리에 저장됩니다. 일반적으로 CSS 등 비스크립트는 메모리에 저장됩니다.
브라우저 캐시 분류
강한 캐시
협상 캐시
브라우저는 서버에 리소스를 요청할 때 먼저 Strong 캐시에 도달했는지 확인하고, 실패하면 적중 여부를 확인합니다. 협상 캐시
Strong Cache
브라우저가 리소스를 로드할 때 먼저 로컬 캐시 리소스의 헤더를 기반으로 강력한 캐시에 도달했는지 여부를 결정합니다. , 캐시의 리소스가 직접 사용되며 서버가 요청을 다시 보내지 않습니다. header中判断是否命中强缓存，如果命中则直接使用缓存中的资源，不会再向服务器发送请求。 （这里的header中的信息指的是 expires 和 cache-control）
Expires
该字段是 http1.0 时的规范，它的值为一个绝对时间的 GMT 格式的时间字符串，比如 Expires:Mon,18 Oct 2066 23:59:59 GMT。这个时间代表着这个资源的失效时间，在此时间之前，即命中缓存。这种方式有一个明显的缺点，由于失效时间是一个绝对时间，所以当服务器与客户端时间偏差较大时，就会导致缓存混乱。所以这种方式很快在后来的HTTP1.1版本中被抛弃了。
当强缓存没命中时，浏览器会发送一个请求到服务器，服务器根据 header 中的信息来判断是否命中协商缓存。如果命中，则返回304 ，告诉浏览器资源未更新，可以使用本地缓存。 （这里的header信息指的是Last-Modify/If-Modify-Since 和 ETag/If-None-Match(여기 헤더의 정보는 expires 및 cache-control을 참조합니다.)
Expires
이 필드는
http1.0
입니다. 시간 지정의 경우 해당 값은 Expires:Mon,18 Oct 2066 23:59:59 GMT와 같은 GMT 형식의
절대 시간
시간 문자열입니다. 이 시간은 이 시간 이전에 캐시가 적중되는 시간을 나타냅니다. 이 방법은 만료 시간이 절대 시간이기 때문에 서버와 클라이언트 사이의 시간 편차가 클 경우 캐시 혼란이 발생한다는 명백한 단점이 있습니다. 따라서 이 방법은 이후 버전의 HTTP 1.1에서 빠르게 폐기되었습니다.
Cache-Control
Cache-Control은 http1.1일 때 나타나는 헤더 정보로 주로 이 필드의
max-age
값을 사용하여 판단합니다. 상대 시간
예를 들어 Cache-Control:max-age=3600은 리소스 유효 기간이 3600초임을 의미합니다. 이 필드 외에도 캐시 제어에는 일반적으로 사용되는 다음과 같은 설정 값도 있습니다.
no-cache
: 캐시를 협상하고 서버에 캐시 사용 여부를 확인하는 요청을 보내야 합니다.
no-store
: 캐싱을 비활성화하고 매번 데이터를 다시 요청합니다.
public: 최종 사용자 및 CDN과 같은 중간 프록시 서버를 포함한 모든 사용자가 캐시할 수 있습니다.
private: 최종 사용자의 브라우저에서만 캐시할 수 있으며 CDN과 같은 릴레이 캐시 서버에서는 캐시가 허용되지 않습니다.
캐시 제어 및 만료는 서버 구성에서 동시에 활성화할 수 있습니다. 동시에 활성화하면 캐시 제어의 우선 순위가 높아집니다.
협상 캐시🎜🎜강한 캐시가 누락되면 브라우저는 서버에 요청을 보내고 서버는 헤더의 정보를 기반으로 협상 캐시 적중 여부를 결정합니다. . 적중하면 🎜304🎜가 반환되어 리소스가 업데이트되지 않았으며 로컬 캐시를 사용할 수 있음을 브라우저에 알립니다. 🎜(여기서 헤더 정보는 Last-Modify/If-Modify-Since 및 ETag/If-None-Match를 참조합니다.)🎜🎜🎜🎜🎜🎜Last-Modify / If-Modify-Since🎜🎜🎜🎜🎜브라우저가 처음으로 리소스를 요청할 때 서버가 반환한 헤더에 Last-Modify가 추가됩니다. Last-modify는 리소스의 마지막 수정 시간을 식별하는 시간입니다. . 🎜🎜브라우저가 리소스를 다시 요청하면 요청 헤더에는 캐싱 전에 반환된 Last-Modify인 If-Modify-Since가 포함됩니다. 서버는 If-Modify-Since를 수신한 후 리소스의 마지막 수정 시간을 기준으로 캐시 적중 여부를 결정합니다. 🎜🎜캐시 적중 시 304가 반환되고 리소스 콘텐츠가 반환되지 않으며 Last-Modify가 반환되지 않습니다. 🎜🎜단점: 🎜🎜단기간 내에 리소스가 변경되면 Last-Modified는 변경되지 않습니다. 🎜🎜주기적인 변화. 이 리소스가 한 사이클 내에서 다시 원래 상태로 수정되면 캐시할 수 있다고 생각하지만 Last-Modified는 그렇지 않다고 생각하므로 ETag가 있습니다. 🎜🎜🎜🎜🎜ETag/If-None-Match🎜🎜🎜🎜🎜Last-Modify/If-Modify-Since와의 차이점은 Etag/If-None-Match가 확인 코드를 반환한다는 것입니다. ETag는 각 리소스가 고유하다는 것을 보장할 수 있으며 리소스 변경으로 인해 ETag 변경이 발생합니다. 서버는 브라우저에서 보낸 If-None-Match 값을 기반으로 캐시 적중 여부를 결정합니다. 🎜🎜Last-Modified와의 차이점은 서버가 304 Not Modified 응답을 반환할 때 ETag가 다시 생성되었으므로 ETag가 이전 태그와 변경되지 않았더라도 응답 헤더에 ETag가 반환된다는 것입니다. 🎜🎜🎜Last-Modified와 ETag를 함께 사용할 수 있습니다. 서버는 ETag가 일치하는지 먼저 확인하고 Last-Modified를 계속 비교한 후 최종적으로 304를 반환할지 결정합니다. 🎜🎜🎜🎜🎜Summary🎜🎜🎜🎜🎜브라우저가 이미 방문한 리소스에 액세스할 때 단계는 다음과 같습니다. 🎜🎜🎜1 먼저 강력한 캐시에 도달했는지 확인하세요. 캐시를 직접 사용하세요🎜🎜2. .강한 캐시에 도달하지 않으면 요청이 서버로 전송되어 협상 캐시에 도달했는지 확인합니다. 🎜🎜3. 협상 캐시에 도달하면 서버는 304를 반환하여 브라우저에 로컬 캐시가 있음을 알립니다. 4. 협상 캐시에 도달하지 않으면 서버는 새 리소스를 브라우저에 반환합니다🎜
13.什么是浏览器的同源策略，以及跨域？
同源策略
同源策略是浏览器的一种自我保护行为。所谓的同源指的是：协议，域名，端口均要相同
浏览器中大部分内容都是受同源策略限制的，但是以下三个标签不受限制：
<img src="..." / alt="이 브라우저 인터뷰 질문을 살펴보세요. 몇 개나 정답을 맞힐 수 있나요?" >
<link href="..." />
<script src="..."></script>
해커는 피해자의 쿠키를 사용하여 서버의 신뢰를 속일 수 있지만, 해커는 **"쿠키"**를 얻을 수 없으며 **"쿠키"cookie 骗取服务器的信任，但是黑客并不能凭借拿到**「cookie」**，也看不到 **「cookie」的内容。另外，对于服务器返回的结果，由于浏览器「同源策略」**的限制，黑客也无法进行解析。
这就告诉我们，我们要保护的对象是那些可以直接产生数据改变的服务，而对于读取数据的服务，则不需要进行CSRF의 내용을 볼 수 없습니다. 또한 브라우저의 "동일 출처 정책"**의 제한으로 인해 해커는 서버에서 반환된 결과를 구문 분석할 수 없습니다. 이는 우리가 보호하려는 객체가 데이터 변경을 직접 생성할 수 있는 서비스이며, 데이터를 읽는 서비스의 경우 CSRF 보호가 필요하지 않음을 알려줍니다. 보호의 핵심은
"해커가 위조할 수 없는 정보를 요청에 넣는 것"입니다
원본 탐지
대부분의 CSRF는 타사 웹사이트에서 제공되므로 외부 도메인(또는 신뢰할 수 있는 도메인이 아님)을 직접 금지합니다. 이름) 우리에게 요청하십시오.
그렇다면 질문은 요청이 외부 도메인에서 오는지 어떻게 판단할 수 있느냐는 것입니다.
HTTP 프로토콜에서 각 비동기 요청에는 원본 도메인 이름을 표시하는 두 개의 헤더가 있습니다.
Origin Header
Referer Header
브라우저가 요청을 시작할 때 이 두 헤더는 대부분의 경우 자동으로 가져옵니다. 콘텐츠는 프런트 엔드에서 맞춤설정할 수 없습니다. 서버는 이 두 헤더의 도메인 이름을 구문 분석하여 요청의 소스 도메인을 결정할 수 있습니다.
Origin 헤더를 사용하여 소스 도메인 이름을 결정하세요
일부 CSRF 관련 요청에서는 Origin 필드가 요청된 헤더에 전달됩니다. 필드에는 요청된 도메인 이름(경로 및 쿼리 제외)이 포함됩니다.
Origin이 존재하는 경우 Origin의 필드를 사용하여 원본 도메인 이름을 직접 확인할 수 있습니다.
그러나 다음 두 가지 경우에는 Origin이 존재하지 않습니다.
IE11 동일한 Origin 정책: IE 11은 사이트 간 CORS 요청에 Origin 헤더를 추가하지 않으며 Referer 헤더는 여전히 고유 식별자입니다. 가장 근본적인 이유는 IE 11의 동일 출처에 대한 정의가 다른 브라우저와 다르기 때문입니다. 두 가지 주요 차이점은
MDN Same-origin_policy#IE_Exceptions
302 리디렉션을 참조하세요.
302 리디렉션 이후의 출처는 포함되지 않습니다. Origin으로 인해 리디렉션된 요청은 다른 소스의 민감한 정보로 간주될 수 있습니다. 302 리디렉션의 경우 URL이 새 서버로 연결되므로 브라우저는 원본을 새 서버로 유출하는 것을 원하지 않습니다.
Referer 헤더를 사용하여 소스 도메인 이름 결정
HTTP 프로토콜에 따르면 HTTP 헤더에는 HTTP 요청의 소스 주소를 기록하는 Referer라는 필드가 있습니다. Ajax 요청, 이미지 및 스크립트와 같은 리소스 요청의 경우 리퍼러는 요청을 시작하는 페이지 주소입니다. 페이지 점프의 경우 Referer는 페이지 기록을 연 이전 페이지의 주소입니다. 따라서 리퍼러 링크의 원본 부분을 사용하여 요청의 소스 도메인 이름을 알 수 있습니다.
이 방법은 완벽하지 않습니다. HTTP 프로토콜에 대한 명확한 요구 사항이 있지만 각 브라우저에는 서로 다른 Referer 구현이 있을 수 있습니다. 브라우저 자체에 보안 취약점이 없다는 보장은 없습니다. . Referer 값을 확인하는 방법은 보안을 보장하기 위해 제3자(즉, 브라우저)에 의존합니다. 이는 이론적으로 그다지 안전하지 않습니다. 어떤 경우에는 공격자가 요청한 리퍼러를 숨기거나 수정할 수도 있습니다.
2014년 W3C의 웹 애플리케이션 보안 실무 그룹은 브라우저가 리퍼러를 보내는 방법에 대한 자세한 조항을 담은 리퍼러 정책 초안을 발표했습니다. 현재 대부분의 새로운 브라우저는 이 초안을 지원하고 있으며 마침내 우리 웹사이트의 추천자 전략을 유연하게 제어할 수 있게 되었습니다. 새 버전의 리퍼러 정책은 리퍼러 없음, 다운그레이드 시 리퍼러 없음, 원본만, 원본 간 원본, 안전하지 않은 URL 등 5가지 리퍼러 정책을 규정합니다. 세 가지 기존 전략인 never, default 및 Always는 새 표준에서 이름이 변경되었습니다. 해당 대응은 다음과 같습니다.
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
