DNS（Domain Name System）
DNS全稱是Domain Name System，中文意思就是域名系統，主要的做用就是將域名解析成IP地址。javascript
那麼爲何要將域名解析成IP地址呢？css
互聯網設備之間的訪問實際上是經過IP地址來進行訪問的，咱們每臺電腦都有本身對應的獨立的IP。java
咱們的網站是存放在服務器上的，那麼要想在互聯網上經過域名來找到對應的服務器，就必需將域名解析成IP地址，而後再根據IP地址去訪問對應的服務器。linux
域名方便記憶，而IP地址比較難記住。nginx
本地的hosts文件數據庫
通常的，當咱們在瀏覽器裏面輸入一個網址的時候，首先會先訪問咱們本地的hosts文件（本地的DNS），若是hosts文件中沒有找到域名對應的IP地址，那麼就會向下一級查詢，通常是運營商的DNS服務器，若是還沒找到那就往下繼續查到國家的根服務器等等，最後若是都沒找到的話，那麼說明這個域名沒有被解析過。apache
windows系統的hosts文件是在C:\system32\drives\ets\hostswindows
linux或mac是在/etc/hosts瀏覽器
咱們能夠經過修改本地的hosts文件來達到快速訪問或自定義訪問的目的。緩存
好比作測試的時候，咱們想隨便取一個域名作測試，那麼就能夠經過修改本地的hosts文件來實現。
或者咱們不想訪問某個域名，也能夠經過修改本地的hosts文件實現。
別人的電腦是沒法訪問到你電腦的hosts的，因此本地的hosts的影響只是針對你的電腦自己，對其餘人的訪問無影響。要想讓全部人都能經過你的域名訪問到你的站點，那麼就必需使用第三方機構提供的DNS服務器來對域名在公網上進行解析和綁定。
通常的，主要是經過DNS服務器對域名進行解析綁定。DNS服務器通常由域名商提供，市面上有不少的DNS服務器，國內比較著名的有萬網、西部數碼、新網、dnspod、易名中國、聚名網等，國外的有godaddy（狗大爹）、namesoilo、Namecheap等。
當咱們進行域名解析綁定的時候，會有解析記錄的類型選擇。通常的有：
A記錄：直接是域名和IPV4地址對應的，能夠對域名進行泛解析
CNAME記錄：別名解析記錄，能夠解析到另外一個域名
MX記錄：通常用於郵箱，指向的是郵箱服務器地址
AAAA記錄：指向的是IPV6的地址，由於IPV4的地址已經不夠用了，目前也已經開始慢慢的使用IPV6了
TXT記錄：這個用於反垃圾郵件用的，也能夠用於驗證。Google的search console就是用TXT記錄進行站點的驗證。
既然解析是用到DNS服務器，那麼確定的會有一個解析速度快慢和穩定性的問題存在。所以選擇一個大的服務器商在速度和穩定性上都會有很好的保證。並且大的服務器上在各類線路上都比較強大，不至於電信解析慢而聯通和移動解析快。
大規模網絡爬蟲抓取效率問題
這裏爲何要提這個問題呢？由於像百度等商業化搜索引擎用到的都是大規模的網絡爬蟲，而咱們都知道，要想訪問一個頁面，就必須先經過域名解析拿到網站的IP，而後經過IP地址去找到對應的服務器，而後再從服務器拿到網頁的數據。
那麼爲了提升抓取的效率，搜索引擎爬蟲都會有本身的DNS服務器，這樣只須要第一次訪問的時候拿到網站的IP，而後記錄到本身的DNS服務器上，之後訪問的時候都從本身的DNS服務器上直接獲取到IP地址，就不用去請求第三方的DNS服務器，從而提升速度和效率。
這也就是爲何咱們更換了網站的IP以後要去站長平臺作抓取診斷的緣由，不少時候都會發現抓取的仍是原來的IP，這個時候就須要點擊糾錯來告訴百度，我這個IP換了，再也不是原來的了。基本過幾分鐘以後再去作抓取診斷就能抓取成功新的IP。
HTTP和HTTPS協議
HTTP協議
HTTP協議是Hyper Text Transfer Protocol（超文本傳輸協議）的縮寫,是用於從萬維網（WWW:World Wide Web ）服務器傳輸超文本到本地瀏覽器的傳送協議。
HTTP是一個基於TCP/IP通訊協議來傳遞數據（HTML 文件, 圖片文件, 查詢結果等）。
主要特色
無鏈接
無鏈接的含義是限制每次鏈接只處理一個請求。服務器處理完客戶的請求，並收到客戶的應答後，即斷開鏈接。採用這種方式能夠節省傳輸時間。
無狀態
HTTP協議是無狀態協議。無狀態是指協議對於事務處理沒有記憶能力。缺乏狀態意味着若是後續處理須要前面的信息，則它必須重傳，這樣可能致使每次鏈接傳送的數據量增大。另外一方面，在服務器不須要先前信息時它的應答就較快。
請求報文
HTTP 協議是以 ASCII 碼傳輸，創建在 TCP/IP 協議之上的應用層規範。規範把 HTTP 請求分爲三個部分：狀態行、請求頭、消息主體。相似於下面這樣：
<method> <request-URL> <version><headers>
<entity-body>
HTTP 定義了與服務器交互的不一樣方法，最基本的方法有4種，分別是GET，POST，PUT，DELETE。URL全稱是資源描述符，咱們能夠這樣認爲：一個URL地址，它用於描述一個網絡上的資源，而 HTTP 中的GET，POST，PUT，DELETE就對應着對這個資源的查，增，改，刪4個操做
所謂安全的意味着該操做用於獲取信息而非修改信息。換句話說，GET 請求通常不該產生反作用。就是說，它僅僅是獲取資源信息，就像數據庫查詢同樣，不會修改，增長數據，不會影響資源的狀態。
冪等的意味着對同一 URL 的多個請求應該返回一樣的結果。
好比下面的是請求百度的相關搜索接口的原始請求報文
GET /su?wd=b&action=opensearch&ie=UTF-8 HTTP/1.1Host: suggestion.baidu.comUser-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/76.0.3809.100 Safari/537.36Accept-Encoding: gzip, deflateAccept-Language: zh-CN,zh;q=0.9,en;q=0.8,en-GB;q=0.7Cookie: BIDUPSID=5B9E4D12EA55FAD9625AF12D3EFD1C1B; PSTM=1567676773; BDORZ=B490B5EBF6F3CD402E515D22BCDA1598; BAIDUID=58F8088B4DDA9C155DDC4153CD5A50B6:FG=1; H_WISE_SIDS=130611_124610_129118_120202_135730_132909_131246_130763_132378_131518_118896_118864_118838_118822_118788_107313_132784_133351_132553_129648_132250_127025_134854_128968_135308_133838_133847_132551_135433_135874_134752_129643_131423_135336_135553_134318_136017_110085_127969_132694_131951_135672_135458_128196_135046_135038_135835_132467_134348; H_PS_PSSID=1446_21101_29522_29519_29721_29568_29220_22158; BDUSS=FnemF4TmNxS2pmbn5XRmRRbWw0ZGFBWk1vY0lOSnJ6clVCQVdJN3A0c3JYWnRkSUFBQUFBJCQAAAAAAAAAAAEAAACfotorRG93bmxvYWRzaXIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACvQc10r0HNdS2; PSINO=6; delPer=1; SIGNIN_UC=70a2711cf1d3d9b1a82d2f87d633bd8a03179272500; uc_login_unique=25a66cd6d7873b2f4e41bded0d7d66e5; uc_recom_mark=cmVjb21tYXJrXzI2ODI4MDMwConnection: keep-alive
POST 表示可能修改變服務器上的資源的請求。
POST /form HTTP/1.1 Host: www.example.com : Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Firefox/1.0.1 : application/x-www-form-urlencoded : 40 Connection: Keep-Alive
sex=man&name=Professional
注意：
GET 可提交的數據量受到URL長度的限制，HTTP 協議規範沒有對 URL 長度進行限制。這個限制是特定的瀏覽器及服務器對它的限制
理論上講，POST 是沒有大小限制的，HTTP 協議規範也沒有進行大小限制，出於安全考慮，服務器軟件在實現時會作必定限制
參考上面的報文示例，能夠發現 GET 和 POST 數據內容是如出一轍的，只是位置不一樣，一個在 URL 裏，一個在 HTTP 包的包體裏
響應報文
響應報文跟請求報文都是差很少的結構，由三部分組成：
狀態行
響應頭（Response Header）
響應正文
看下百度相關搜索接口的響應報文：
HTTP/1.1 200 OKCache-Control: privateContent-Length: 79Content-Type: text/javascript; charset=UTF-8Date: Sun, 08 Sep 2019 08:31:01 GMTExpires: Sun, 08 Sep 2019 09:31:01 GMTServer: suggestion.baidu.zbb.dfProxy-Connection: keep-alive
["b",["baidu","bt","btchina","beyond","bbs","bbc","blog","bobo組合","bb霜"]]
狀態行由協議版本、數字形式的狀態代碼、及相應的狀態描述，各元素之間以空格分隔。
常見的狀態碼有以下幾種：
200 OK301 Moved Permanently請求永久重定向302 Moved Temporarily請求臨時重定向304 Not Modified文件未修改，能夠直接使用緩存的文件。400 Bad Request因爲客戶端請求有語法錯誤，不能被服務器所理解。401 Unauthorized請求未經受權。這個狀態代碼必須和WWW-Authenticate報頭域一塊兒使用403 Forbidden服務器收到請求，可是拒絕提供服務。服務器一般會在響應正文中給出不提供服務的緣由404 Not Found請求的資源不存在，例如，輸入了錯誤的URL500 Internal Server Error服務器發生不可預期的錯誤，致使沒法完成客戶端的請求。502 Bad Gateway網關錯誤，這一般並不意味着上游服務器已關閉（無響應網關/代理） ，而是上游服務器和網關/代理使用不一致的協議交換數據。503 Service Unavailable服務器當前不可以處理客戶端的請求，在一段時間以後，服務器可能會恢復正常。
說說持久鏈接
前面說到HTTP協議是無狀態、無鏈接的。這樣子的話每次請求都須要從新創建鏈接，HTTP協議的底層是用的TCP/IP協議，每次簡歷鏈接都須要通過三次握手，很是的浪費服務器端的資源和時間。而當咱們在瀏覽器裏面輸入一個網址的時候，其實不只僅發起一次請求，由於網站中除了網頁自己的文本內容，還包括了css、js、圖片、音視頻等內容，每一個資源都會發起一次請求，若是說每次請求來了都要創建一次鏈接的話那就太耗費資源了，所以就有了持久鏈接keep-alive這個鏈接屬性的目的是告訴服務器，我這個鏈接是持久鏈接，我等下還有其它的資源要請求，你先不要給我斷開。
咱們來看看當咱們在百度裏面輸入一個關鍵詞的時候，都請求了哪些東西：
咱們看最底下的一行，就能夠看到，一共發起了64個請求，有1.3MB的資源，耗時7.83秒。仍是很恐怖的哈。固然了，咱們並不須要等待7.83秒才能看到結果的內容，這是爲何呢？由於不少都是異步請求，百度會先展現搜索結果的文本內容給咱們看，至於其它的圖片什麼的，就在後臺本身自動加載。
咱們點開第一條連接，就能夠看到請求頭中有一個字段信息Connection：Keep-Alive，這就代表它要發起一個持久鏈接的請求。
那麼問題來了，持久鏈接會一直保持下去麼？夠不夠持久？
其實持久鏈接並非一直保持鏈接的，而是達到了固定的時間以後就會斷開，這個就比如咱們去飯店吃飯，一開始來了一個服務員，而後這個服務並非只服務你一我的的，因此當他拿了菜單給你以後會等一會，等了好久你都沒有開始點菜的話那麼他就會走掉了，去服務其餘客戶。等你須要真正點菜的時候再告訴他。否則的話，老闆可就虧大了，資源太浪費。也不能服務更多的客戶。畢竟服務員的數量是有限的，咱們須要資源最大化。服務器也是同樣的，不會讓一我的一直佔用一條鏈接。
那麼這個保持多長時間呢？實際上是能夠本身配置的。在Nginx服務器上就能夠這麼配置：
keepalive_timeout 60;
這個是在http段裏面設置的，也能夠在sever裏面進行設置。上面的設置表示這個持久鏈接保持60秒的時間。
基於HTTP協議，經過SSL或TLS提供加密處理數據、驗證對方身份以及數據完整性保護。
因爲HTTP協議傳輸的內容都是明文的，所以容易被劫持，數據不安全。而HTTPS對數據進行了加密以後，就再也不是明文傳輸了。
HTTPS採用的是非對稱加密（不懂的能夠忽略哈，區塊鏈也是採用非對稱加密技術），所以要想破解內容的話只有拿到公鑰才行。
非對稱加密技術其實就是採用一對祕鑰，稱爲私鑰和公鑰。私鑰就放在服務器上，數據使用私鑰進行加密。而後用公鑰進行解密。公鑰是發放給其它人使用的。同時公鑰進行加密的數據，只能用私鑰進行解密。
其它的全部東西都是跟HTTP同樣的。
視頻下載地址：
連接:https://pan.baidu.com/s/1z5d0SUyS3eOy1ITqwz8s9Q 密碼:wsab
後續的系列的課程都會更新到該連接，請妥善保管。
關注我，一塊兒學習更多SEO知識
點贊分享一下唄？
本文分享自微信公衆號 - brooks的技術小屋（bluekeso）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。