소프트웨어 개발자로서 네트워크 응용 프로그램의 작동 방식에 대한 완전하고 계층 적 이해를 제공하며 여기에는 브라우저, HTTP, HTML, 웹 서버, 요구 사항 처리 등과 같은 이러한 애플리케이션에 사용되는 기술도 포함됩니다.
이 기사는 URL을 입력 할 때 백그라운드에서 발생하는 일에 대해 더 깊이 연구 할 것입니다 ~
1. 우선 브라우저에 원하는 URL을 입력해야합니다 . 2. 브라우저는 도메인 이름의 IP 주소를 검색합니다.내비게이션의 첫 번째 단계는 도메인 이름에 액세스하여 IP 주소를 찾는 것입니다. DNS 검색 프로세스는 다음과 같습니다.
브라우저 캐싱 - 브라우저는 일정 기간 동안 DNS 레코드를 캐시합니다. 흥미롭게도 운영 체제는 브라우저에 DNS 레코드를 저장할 시간을 알려주지 않으므로 다른 브라우저가 자체 고정 시간 (2 분에서 30 분까지)을 저장합니다. 시스템 캐시 - 브라우저 캐시에 필요한 레코드가없는 경우 브라우저는 시스템 호출 (Windows의 GethostByName)을 만듭니다. 이를 통해 시스템 캐시에서 레코드를 얻을 수 있습니다. 라우터 캐시 - 다음으로, 이전 쿼리 요청은 일반적으로 자체 DNS 캐시가있는 라우터로 전송됩니다. ISP DNS 캐시 - 다음으로 확인해야 할 것은 ISP가 DNS를 캐시하는 서버입니다. 해당 캐시 레코드가 일반적으로 찾을 수있는 곳입니다. 재귀 검색-ISP의 DNS 서버는 .com 상단 도메인 이름 서버에서 Facebook의 도메인 이름 서버에 이르기까지 도메인 이름 서버로 시작합니다. 일반적으로 DNS 서버의 캐시에 .com 도메인 이름 서버에 도메인 이름이 있으므로 최상위 서버와의 일치 프로세스가 필요하지 않습니다.DNS 재귀 검색은 다음 그림에 나와 있습니다.
DNS는 약간 걱정입니다. 즉, wikipedia.org 또는 Facebook.com과 같은 전체 도메인 이름은 별도의 IP 주소에 해당하는 것처럼 보입니다. 다행히도이 병목 현상을 제거하는 몇 가지 방법이 있습니다.
루프 DNS는 DNS 조회시 여러 IP를 반환 할 때 솔루션입니다. 예를 들어 Facebook.com은 실제로 4 개의 IP 주소에 해당합니다. 로드 밸런서는 특정 IP 주소로 청소하고 네트워크 요청을 클러스터 서버로 전달하는 하드웨어 장치입니다. 일부 큰 사이트는 일반적 으로이 고가의 고성능로드 밸런서를 사용합니다. 지리적 DNS는 도메인 이름을 사용자의 지리적 위치에 따라 여러 다른 IP 주소로 매핑하여 확장 성을 향상시킵니다. 이러한 방식으로 다른 서버는 동기화 상태를 업데이트 할 수 없지만 정적 컨텐츠를 매핑하는 것이 매우 좋습니다. Anycast 는 여러 물리 호스트를 IP 주소로 매핑하는 라우팅 기술입니다. 유일한 단점은 Anycast 및 TCP 프로토콜이 잘 조정되지 않으므로 해당 솔루션에서는 거의 사용되지 않는다는 것입니다.대부분의 DNS 서버는 Anycast를 사용하여 효율적이고 낮은 대기 시간 DNS 조회를 얻습니다.
3. 브라우저는 웹 서버에 HTTP 요청을 보냅니다.Facebook 홈페이지와 같은 동적 페이지가 있으므로, 개봉 후 브라우저 캐시에서 곧 그리고 즉시 만료 될 것이며, 그들이 읽을 수 없다는 것은 의심의 여지가 없습니다.
따라서 브라우저는 Facebook이있는 서버에 요청을 보냅니다.
http://facebook.com/ http/1.1을 얻으십시오수락 : 응용 프로그램/x-ms- 적용, 이미지/jpeg, application/xaml+xml, [...]
사용자 에이전트 : Mozilla/4.0 (호환 가능; MSIE 8.0; Windows NT 6.1; WOW64; [...]
인코딩 수락 : gzip, deflate
연결 : 계속하십시오
호스트 : Facebook.com
쿠키 : datr = 1265876274- [...]; 로케일 = en_us; lsd = ww [...]; c_user = 2101 [...]
이 요청을 가져 오십시오. http://facebook.com/을 읽을 URL을 정의하십시오. 브라우저 자체는 ( 사용자 에이전트 헤더)를 정의하고 수락하려는 해당 유형 ( 수락 및 수락 인코딩 헤더)을 정의합니다. 연결 헤더는 서버가 후속 요청에 대해 TCP 연결을 닫지 않아야합니다.
이 요청에는 브라우저에서 저장된 도메인 이름의 쿠키 도 포함되어 있습니다. 다른 페이지 요청에서 쿠키는 웹 사이트 상태와 일치하는 핵심 값이라는 것을 이미 알고있을 것입니다. 이런 식으로 쿠키는 로그인 사용자 이름, 서버 할당 암호 및 일부 사용자 설정을 저장합니다. 쿠키는 클라이언트에 텍스트 문서로 저장되고 요청할 때마다 서버로 전송됩니다.
원래 HTTP 요청과 해당 도구를 볼 수있는 많은 도구가 있습니다. 저자는 피들러를 사용하는 것을 선호하며 물론 Firebug와 같은 다른 도구가 있습니다. 이 소프트웨어는 웹 사이트를 최적화 할 때 큰 도움이 될 수 있습니다.
요청을받는 것 외에도 전송되는 다른 유형의 요청이 있으며, 이는 양식을 제출할 때 종종 사용됩니다. URL을 통해 매개 변수를 전달하라는 요청을 보내십시오 (예 : http://robozzle.com/puzzle.aspx?id=85). 요청 본문 헤더 후에 요청을 보내는 매개 변수를 보냅니다.
http://facebook.com/과 같은 슬래시는 중요합니다. 이 경우 브라우저는 슬래시를 안전하게 추가 할 수 있습니다. http://example.com/folderorfile과 같은 주소의 경우 브라우저가 폴더로 파일이 폴더인지 파일인지 알지 못하기 때문에 슬래시를 자동으로 추가 할 수 없습니다. 현재 브라우저는 슬래시없이 주소에 직접 액세스하고 서버는 리디렉션에 응답하여 불필요한 악수를 초래합니다.
4. Facebook 서비스의 영구적 인 리디렉션 응답그림은 Facebook 서버에서 브라우저로 전송 된 응답을 보여줍니다.
HTTP/1.1 301이 영구적으로 움직였습니다캐시 제어 : 비공개, 없음, 매장, 없음, 캐시, 반드시 검증서, 체크 후 = 0,
사전 점검 = 0
만료 : SAT, 01 1 월 2000 00:00:00 GMT
위치 : http://www.facebook.com/
P3P : CP = DSP 법률
프라그마 : 캐시가 없습니다
set-cookie : made_write_conn = 삭제; 만료 = Thu, 12-Feb-2009 05:09:50 GMT;
경로 =/; 도메인 = .facebook.com; httponly
내용 유형 : Text/HTML; charset = utf-8
x- 결석 : 닫습니다
날짜 : 금요일, 2010 년 2 월 12 일 05:09:51 GMT
내용 길이 : 0
서버는 301 영구적 인 리디렉션 응답에 응답하여 브라우저가 http://facebook.com/ 대신 http://www.facebook.com/을 방문합니다.
사용자가보고 싶은 웹 컨텐츠를 직접 보내는 대신 서버가 리디렉션 해야하는 이유는 무엇입니까? 이 질문에 대한 흥미로운 답변이 많이 있습니다.
그 이유 중 하나는 검색 엔진 순위와 관련이 있습니다. 페이지에 http://www.igoro.com/ 및 http://igoro.com/과 같은 두 개의 주소가있는 경우 검색 엔진은 두 웹 사이트로 간주하여 각각의 검색 링크가 감소하여 순위가 낮아집니다. 검색 엔진은 301 개의 영구 리디렉션의 의미를 알고 있으므로 동일한 웹 사이트 순위에 따라 WWW와 WWW없이 주소에 대한 액세스를 분류합니다.
또 다른 것은 다른 주소를 사용하면 캐시 친근감이 악화 될 수 있다는 것입니다. 페이지에 여러 이름이 있으면 캐시에 여러 번 나타날 수 있습니다.
5. 브라우저는 리디렉션 주소를 추적합니다이제 브라우저는 http://www.facebook.com/에 액세스 할 올바른 주소라는 것을 알고 있으므로 다른 GET 요청을 보냅니다.
http://www.facebook.com/ http/1.1을 받으십시오수락 : 응용 프로그램/x-ms- 적용, 이미지/jpeg, application/xaml+xml, [...]
허용 : en-us
사용자 에이전트 : Mozilla/4.0 (호환 가능; MSIE 8.0; Windows NT 6.1; WOW64; [...]
인코딩 수락 : gzip, deflate
연결 : 계속하십시오
쿠키 : lsd = xw [...]; c_user = 21 [...]; x-referer = [...]
호스트 : www.facebook.com
헤더 정보는 이전 요청에서와 동일한 의미를 갖습니다.
6. 서버가 요청을 처리합니다서버는 페치 요청을 수신 한 다음 응답을 처리하고 반환합니다.
이것은 표면의 전진적인 작업 인 것처럼 보이지만 실제로는 중간에 흥미로운 일이 많이 있습니다. 저자의 블로그와 같은 간단한 웹 사이트, Facebook과 같은 웹 사이트는 물론입니다!
웹 서버 소프트웨어 웹 서버 소프트웨어 (예 : IIS 및 Apache)는 HTTP 요청을 수신 한 다음이를 처리하기 위해 수행되는 요청 처리를 결정합니다. 요청 처리는 요청을 읽고 HTML을 생성 할 수있는 프로그램입니다 (예 : ASP.NET, PHP, Ruby ...).가장 간단한 예를 들기 위해 요구 사항 처리는 사이트 주소 구조를 매핑하는 파일 계층에 저장할 수 있습니다. http://example.com/folder1/page1.aspx와 같은 주소는 /httpdocs/folder1/page1.aspx 파일을 매핑합니다. 웹 서버 소프트웨어는 주소로 수동으로 해당 요청 처리로 설정할 수 있으므로 Page1.aspx의 게시 주소는 http://example.com/folder1/page1 일 수 있습니다.
요청 처리 요청은 읽기 요청과 매개 변수 및 쿠키를 처리합니다. 일부 데이터를 읽고 업데이트하고 데이터가 서버에 저장되어 있다고 말합니다. 그런 다음 요구 사항 처리는 HTML 응답을 생성합니다.모든 동적 웹 사이트는 흥미로운 어려움에 직면합니다. 데이터 저장 방법. 소규모 웹 사이트의 절반에는 데이터를 저장할 SQL 데이터베이스가 있습니다. 많은 양의 데이터 및/또는 방문한 웹 사이트를 저장하면 데이터베이스를 여러 시스템에 할당하는 몇 가지 방법을 찾아야합니다. 솔루션에는 다음이 포함됩니다. 샤딩 (기본 키 값, 데이터 테이블은 여러 데이터베이스에 산란), 복제 및 약한 의미 론적 일관성을 활용하는 단순화 된 데이터베이스가 포함됩니다.
배치 처리로 작업을 위임하는 것은 데이터를 업데이트하는 저렴한 기술입니다. 예를 들어, Facebook은 뉴스 피드를 제 시간에 업데이트해야하지만 데이터 지원을 통해 알 수있는 사람들의 기능은 매일 밤 만 업데이트되면됩니다 (저자는 기능을 향상시키는 방법은 알려져 있지 않음). 배치 작업 업데이트로 인해 덜 중요한 데이터가 구식이 될 수 있지만 데이터 업데이트를 더 빠르고 간결하게 만들 수 있습니다.
7. 서버는 HTML 응답을 다시 보냅니다이미지는 서버가 생성하고 반환 한 응답입니다.
HTTP/1.1 200 OK캐시 제어 : 비공개, 없음, 매장, 없음, 캐시, 반드시 검증서, 체크 후 = 0,
사전 점검 = 0
만료 : SAT, 01 1 월 2000 00:00:00 GMT
P3P : CP = DSP 법률
프라그마 : 캐시가 없습니다
컨텐츠 인코딩 : GZIP
내용 유형 : Text/HTML; charset = utf-8
x- 결석 : 닫습니다
전송 인코딩 : 청크
날짜 : 금요일, 2010 년 2 월 12 일 09:05:55 GMT
2B3TN@[...]
전체 응답 크기는 35KB이며, 대부분 정렬 후 Blob 유형으로 전송됩니다.
컨텐츠 인코딩 터미널은 브라우저에 전체 응답 본문이 GZIP 알고리즘을 사용하여 압축되어 있음을 알려줍니다. Blob Block을 압축 한 후 예상 HTML을 다음과 같이 볼 수 있습니다.<! doctype html public- // w3c // dtd xhtml 1.0 엄격한 // enhttp://www.w3.org/tr/xhtml1/dtd/xhtml1-strict.dtd>
<html xmlns = http : //www.w3.org/1999/xhtml xml : lang = en
lang = en id = facebook 클래스 = no_js>
<헤드>
<meta http-equiv = content-type content = text/html; charset = utf-8 />
<meta http-equiv = content-language content = en />
...
압축과 관련하여 헤더 정보는이 페이지가 캐시되어 있는지, 캐시 된 경우 수행하는 방법, 설정 해야하는 쿠키 (이 점은 이전 응답에서는 찾을 수 없음), 개인 정보 정보 정보 등을 설명합니다.
내용 유형은 헤더에서 텍스트/html 로 설정되어 있습니다. 헤더를 사용하면 브라우저가 파일 양식으로 다운로드하는 대신 응답 내용을 HTML로 렌더링 할 수 있습니다. 브라우저는 헤더 정보를 기반으로 응답을 해석하는 방법을 결정하지만 URL 확장 콘텐츠와 같은 다른 요소도 고려할 것입니다.
8. 브라우저가 HTML을 표시하기 시작합니다브라우저가 모든 HTML 문서를 완전히 허용하지 않으면이 페이지가 표시되기 시작합니다.
9. 브라우저는 HTML에 내장 된 개체를 얻기 위해 보냅니다.브라우저에 HTML이 표시되면 다른 주소의 내용을 가져 오는 데 필요한 태그를 알 수 있습니다. 현재 브라우저는 파일을 되 찾으 그들의 GET 요청을 보냅니다.
다음은 Facebook.com을 방문 할 때 다시 준비 해야하는 몇 가지 URL입니다.
그림 http://static.ak.fbcdn.net/rsrc.php/z12e0/hash/8q2anwu7.gifhttp://static.ak.fbcdn.net/rsrc.php/zbs5c/hash/7hwy7at6.gif
… CSS 스타일 테이블
http://static.ak.fbcdn.net/rsrc.php/z448z/hash/2plh8s4n.css
http://static.ak.fbcdn.net/rsrc.php/zane1/hash/cvtutcee.css
… JavaScript 파일
http://static.ak.fbcdn.net/rsrc.php/zemoa/hash/c8yzb6ub.js
http://static.ak.fbcdn.net/rsrc.php/z6r9l/hash/cq2lgbs8.js
…
이 주소는 모두 HTML 읽기와 유사한 프로세스를 거칩니다. 따라서 브라우저는 DNS에서 이러한 도메인 이름을 찾거나 요청 보내기, 리디렉션 등을 찾습니다.
그러나 동적 페이지와 달리 정적 파일을 사용하면 브라우저가 캐시 할 수 있습니다. 일부 파일은 서버와 통신 할 필요가 없으며 캐시에서 직접 읽을 수 있습니다. 서버의 응답에는 정적 파일의 마감일 정보가 포함되어 있으므로 브라우저는 캐싱 해야하는 시간을 알고 있습니다. 또한 각 응답에는 버전 번호와 같은 작동하는 ETAG 헤더 (요청 된 변수의 엔티티 값)가 포함될 수 있습니다. 브라우저에서 파일의 버전 ETAG 정보가 이미 존재한다는 것을 관찰하면 파일의 전송이 즉시 중지됩니다.
주소에서 FBCDN.NET 가 무엇을 나타내는 지 추측하십시오. 영리한 대답은 Facebook Content Distribution Network입니다. Facebook은 CDN (Content Distribution Network)을 사용하여 이미지, CSS 테이블 및 JavaScript 파일과 같은 정적 파일을 배포합니다. 따라서이 파일은 전 세계의 많은 CDN 데이터 센터에서 백업됩니다.
정적 컨텐츠는 종종 사이트의 대역폭 크기를 나타내며 CDN을 통해 쉽게 복사 할 수 있습니다. 일반적으로 웹 사이트는 타사 CDN을 사용합니다. 예를 들어 Facebook의 정적 파일은 가장 큰 CDN 제공 업체 인 Akamai가 호스팅합니다.
예를 들어, static.ak.fbcdn.net을 핑하려고하면 특정 akamai.net 서버에서 응답을받을 수 있습니다. 흥미롭게도 다시 핑하면 응답 서버가 다를 수 있습니다. 즉, 장면 뒤에서로드 밸런스가 작동하기 시작합니다.
10. 브라우저는 비동기식 (AJAX) 요청을 보냅니다Web 2.0의 위대한 정신에 따라 페이지 디스플레이가 완료된 후 클라이언트는 서버와 접촉하고 있습니다.
Facebook 채팅 기능을 예로 들어 서버와 연락하여 밝고 회색 친구 상태를 적시에 업데이트합니다. 이 아바타의 친구 상태를 업데이트하기 위해 브라우저에서 실행 된 JavaScript 코드는 서버에 비동기 요청을 보냅니다. 이 비동기 요청은 특정 주소로 전송되며, 이는 프로그램으로 구성된 페치 또는 보내기 요청입니다. 또는 Facebook 예제에서 클라이언트는 http://www.facebook.com/ajax/chat/buddy_list.php에 요청을 보내 친구의 온라인 상태 정보를 얻습니다.
이 패턴에 관해서는 Ajax (Asynchronous javaScript 및 XML에 대해 이야기해야합니다. 서버가 XML 형식으로 응답하는 명백한 이유는 없지만. 또 다른 예를 드리겠습니다. 비동기 요청의 경우 Facebook은 일부 JavaScript 코드 스 니펫을 반환합니다.
무엇보다도 Fiddler 도구를 사용하면 브라우저에서 보낸 비동기 요청을 볼 수 있습니다. 실제로, 당신은 이러한 요청의 관중 역할을 할뿐만 아니라 적극적으로 공격하여이를 수정하고 재판매 할 수 있습니다. Ajax 요청은 속보는 것이 너무 쉽지만 실제로 점수를 매기는 온라인 게임 개발자는 우울합니다. (물론, 그런 다른 사람들에게 거짓말을하지 마십시오 ~)
Facebook 채팅 기능은 AJAX의 흥미로운 사례를 제공합니다. 서버에서 클라이언트로 데이터를 푸시합니다. HTTP는 요청-응답 프로토콜이므로 채팅 서버는 새 메시지를 클라이언트에 보낼 수 없습니다. 대신, 클라이언트는 몇 초마다 서버 측을 설문 조사하여 새로운 뉴스가 있는지 확인해야합니다.
이러한 상황에 대한 폴링은 서버로드를 줄이는 흥미로운 기술입니다. 서버에 설문 조사에 새 메시지가 없으면 클라이언트를 무시합니다. 클라이언트의 새 메시지가 아직 시간을 초과하지 않으면 서버는 미완성 요청을 찾아서 새 메시지를 클라이언트에게 응답으로 반환합니다.