接連幾天的面試，讓我對自己都產(chǎn)生懷疑了。面試官隨便一問，就能問到知識盲區(qū)?；蛘呙嬖嚬僖簧钊?，就懵逼狀態(tài)。尤其是好多很確定曾經(jīng)會過，學(xué)過的東西，現(xiàn)在忘得就剩個印象了。所以打算正好趁這幾天沒工作，比較閑，把曾經(jīng)的筆記都整理出來。以來算是復(fù)習(xí)一遍，加深印象。而來從紙質(zhì)到簡書，以后在找起來也方便。最后順便分享給大家，如果覺得幫到你了點(diǎn)個喜歡點(diǎn)個關(guān)注啥的。
我所整理的東西都是曾經(jīng)看視頻，帖子，或者某個大佬說的話最后寫成的筆記。現(xiàn)在相當(dāng)于把筆記重新整理成一篇文章。所以哪怕有一些引用也找不到出處了，就不標(biāo)明了！
什么是HTTP協(xié)議？
HTTP協(xié)議是超文本傳輸協(xié)議（默認(rèn)端口80）。
服務(wù)器傳輸超文本到本地瀏覽器的傳送協(xié)議。
HTTP是一個基于TCP/IP通信協(xié)議來傳送數(shù)據(jù)的。
HTTP就是客服端→服務(wù)端的數(shù)據(jù)傳輸。
大致工作流程：
（1）客戶與服務(wù)器建立連接；
（2）客戶向服務(wù)器提出請求；
（3）服務(wù)器接受請求，并根據(jù)請求返回相應(yīng)的文件作為應(yīng)答；
（4）客戶與服務(wù)器關(guān)閉連接。
HTTP的特征：
1. 無連接（HTTP 的設(shè)計(jì)者有意利用這種特點(diǎn)將協(xié)議設(shè)計(jì)為請求時建連接、請求完釋放連接，以盡快將資源釋放出來服務(wù)其他客戶端。）。
正常默認(rèn)是短鏈接：建立連接→傳送數(shù)據(jù)→關(guān)閉連接。
但是隨著發(fā)展，發(fā)現(xiàn)有時候每次訪問都需要建立一次 TCP 連接就顯得很低效。后來，Keep-Alive 被提出用來解決這效率低的問題。就是長連接。
可以設(shè)置為長連接：建立連接→傳送數(shù)據(jù)→傳送數(shù)據(jù)→...→關(guān)閉連接。
其實(shí)長連接還分為兩種（完全理論知識，我沒實(shí)際操作過。視頻里講的）：
- without pipdining：收到上一個請求響應(yīng)后才能發(fā)下一個。
- with pipdining：不管響沒響應(yīng)，都可以再發(fā)請求。
長短連接的優(yōu)缺點(diǎn)：
像WEB網(wǎng)站的http服務(wù)一般都用短鏈接，因?yàn)殚L連接對于服務(wù)端來說會耗費(fèi)一定的資源，而像WEB網(wǎng)站這么頻繁的成千上萬甚至上億客戶端的連接用短連接會更省一些資源，如果用長連接，而且同時有成千上萬的用戶，如果每個用戶都占用一個連接的話，那可想而知吧。所以并發(fā)量大，但每個用戶無需頻繁操作情況下需用短連好。
長連接是為了節(jié)省每次請求都要建立新連接所需要的時間，還節(jié)約帶寬。多用于操作頻繁，點(diǎn)對點(diǎn)的通訊，而且連接數(shù)不能太多情況。每個TCP連接都需要三步握手，這需要時間，如果每個操作都是先連接，再操作的話那么處理速度會降低很多，所以每個操作完后都不斷開，次處理時直接發(fā)送數(shù)據(jù)包就OK了，不用建立TCP連接。例如：數(shù)據(jù)庫的連接用長連接， 如果用短連接頻繁的通信會造成socket錯誤，而且頻繁的socket 創(chuàng)建也是對資源的浪費(fèi)。
2. HTTP是媒體獨(dú)立的（不同的地方有不同的說法，我這里按照視頻里講解的說了。我也在別的地方看到的http特點(diǎn)不是這么講的，別較真）。
因?yàn)閠cp傳輸?shù)氖菆笪亩?，所以任何類型都可以傳輸。只要客戶端和服?wù)端達(dá)成一致即可。
3. HTTP是無狀態(tài)的（這個無連接和無狀態(tài)是統(tǒng)一說法，沒啥好撕的）。
通俗一點(diǎn)的理解就是：啥也不記。
優(yōu)缺點(diǎn)都有：缺點(diǎn)是如果需要之前的數(shù)據(jù)必須重新傳，比較麻煩。但是如果不需要數(shù)據(jù)則正好，應(yīng)答較快。
這里有一點(diǎn)要注意：HTTP 是一個無狀態(tài)協(xié)議，這意味著每個請求都是獨(dú)立的，Keep-Alive 沒能改變這個結(jié)果。所以我們所謂的長連接只不過不用每次新建連接，但是每一次的請求還是獨(dú)立的。
這些就是我之前在視頻里看到的并且總結(jié)的知識點(diǎn)。然后因?yàn)閷戇@篇文章所以還額外找了一些資料?？吹搅肆硪环N關(guān)于http特征的說法，在這里粘貼一下，文章的最后我會貼上參考鏈接的。
HTTP協(xié)議的主要特點(diǎn)可概括如下：
1.支持客戶/服務(wù)器模式。
2.簡單快速：客戶向服務(wù)器請求服務(wù)時，只需傳送請求方法和路徑。請求方法常用的有GET、HEAD、POST。每種方法規(guī)定了客戶與服務(wù)器聯(lián)系的類型不同。由于HTTP協(xié)議簡單，使得HTTP服務(wù)器的程序規(guī)模小，因而通信速度很快。
3.靈活：HTTP允許傳輸任意類型的數(shù)據(jù)對象。正在傳輸?shù)念愋陀蒀ontent-Type（Content-Type是HTTP包中用來表示內(nèi)容類型的標(biāo)識）加以標(biāo)記。
4.無連接：無連接的含義是限制每次連接只處理一個請求。服務(wù)器處理完客戶的請求，并收到客戶的應(yīng)答后，即斷開連接。采用這種方式可以節(jié)省傳輸時間。
5.無狀態(tài)：HTTP協(xié)議是無狀態(tài)協(xié)議。無狀態(tài)是指協(xié)議對于事務(wù)處理沒有記憶能力。缺少狀態(tài)意味著如果后續(xù)處理需要前面的信息，則它必須重傳，這樣可能導(dǎo)致每次連接傳送的數(shù)據(jù)量增大。另一方面，在服務(wù)器不需要先前信息時它的應(yīng)答就較快。
我們通過對比可以發(fā)現(xiàn)，其實(shí)主要的兩個不改變的就是無狀態(tài)，無連接。然后這里的簡單快速和靈活的原因就是因?yàn)橹С挚蛻?服務(wù)器模式。也就是媒體獨(dú)立?？偟膩碚f，大概意思是差不多的。
TCP協(xié)議 （傳輸控制協(xié)議）
上面說http的時候一直有提到tcp協(xié)議。這里專門講一下什么是tcp協(xié)議：
傳輸控制協(xié)議（TCP，Transmission Control Protocol）是為了在不可靠的互聯(lián)網(wǎng)絡(luò)上提供可靠的端到端字節(jié)流而專門設(shè)計(jì)的一個傳輸協(xié)議。
這個是百度百科的介紹。其實(shí)很好理解。為了端到端的數(shù)據(jù)傳輸而專門設(shè)計(jì)的。
用一個我個人的想象的理解：旅行箱/書包/塑料袋是為了我們在一個地方到另一個地方的攜帶/運(yùn)輸而設(shè)計(jì)的。如果我從超市買一大堆東西，沒有任何包裝工具（袋子，箱子，盒子啥的），一起在懷里捧著，可能到家會發(fā)現(xiàn)半路上丟了東西。本來想吃火鍋，啥都買好了捧到家發(fā)現(xiàn)火鍋料丟了。完了，整個計(jì)劃都不能實(shí)現(xiàn)了。
同樣的道理，兩個端數(shù)據(jù)傳輸，我們起碼得保證傳送的和接受的要一樣吧？不然一會兒丟個字節(jié)，一會兒丟個段落，最后傳過去的東西接收方都看不明白，那還有什么意義了？由此，tcp就是這么一個保證文件傳輸過程中不會丟減字節(jié)的協(xié)議。
接下來我直接貼上百度百科對tcp的介紹，有空的同學(xué)可以看一下，不太復(fù)雜。
TCP是一種面向廣域網(wǎng)的通信協(xié)議，目的是在跨越多個網(wǎng)絡(luò)通信時，為兩個通信端點(diǎn)之間提供一條具有下列特點(diǎn)的通信方式： [1]
（1）基于流的方式；
（2）面向連接；
（3）可靠通信方式；
（4）在網(wǎng)絡(luò)狀況不佳的時候盡量降低系統(tǒng)由于重傳帶來的帶寬開銷；
（5）通信連接維護(hù)是面向通信的兩個端點(diǎn)的，而不考慮中間網(wǎng)段和節(jié)點(diǎn)。
為滿足TCP協(xié)議的這些特點(diǎn)，TCP協(xié)議做了如下的規(guī)定： [10]
①數(shù)據(jù)分片：在發(fā)送端對用戶數(shù)據(jù)進(jìn)行分片，在接收端進(jìn)行重組，由TCP確定分片的大小并控制分片和重組；
②到達(dá)確認(rèn)：接收端接收到分片數(shù)據(jù)時，根據(jù)分片數(shù)據(jù)序號向發(fā)送端發(fā)送一個確認(rèn)；
③超時重發(fā)：發(fā)送方在發(fā)送分片時啟動超時定時器，如果在定時器超時之后沒有收到相應(yīng)的確認(rèn)，重發(fā)分片；
④滑動窗口：TCP連接每一方的接收緩沖空間大小都固定，接收端只允許另一端發(fā)送接收端緩沖區(qū)所能接納的數(shù)據(jù)，TCP在滑動窗口的基礎(chǔ)上提供流量控制，防止較快主機(jī)致使較慢主機(jī)的緩沖區(qū)溢出；
⑤失序處理：作為IP數(shù)據(jù)報來傳輸?shù)腡CP分片到達(dá)時可能會失序，TCP將對收到的數(shù)據(jù)進(jìn)行重新排序，將收到的數(shù)據(jù)以正確的順序交給應(yīng)用層；
⑥重復(fù)處理：作為IP數(shù)據(jù)報來傳輸?shù)腡CP分片會發(fā)生重復(fù)，TCP的接收端必須丟棄重復(fù)的數(shù)據(jù)；
⑦數(shù)據(jù)校驗(yàn)：TCP將保持它首部和數(shù)據(jù)的檢驗(yàn)和，這是一個端到端的檢驗(yàn)和，目的是檢測數(shù)據(jù)在傳輸過程中的任何變化。如果收到分片的檢驗(yàn)和有差錯，TCP將丟棄這個分片，并不確認(rèn)收到此報文段導(dǎo)致對端超時并重發(fā)。
上面的通信方式讓我們對tcp有一個更清晰的認(rèn)識。
下面的規(guī)定都是為了保證傳遞過程中數(shù)據(jù)不會變。保證發(fā)送的和接受的是一樣一樣的東西。（就好像塑料袋的作用是裝進(jìn)袋子里的東西和到家以后從袋子里拿出來的東西是一樣的。別跟我說什么袋子壞掉了，路上偷吃了什么的情況?。。。。┤缓笪矣X得概念還好理解。而且做法也通俗易懂的。一會兒下面還會有提到。
IP
IP地址是IP協(xié)議提供的一種統(tǒng)一的地址格式，它為互聯(lián)網(wǎng)上的每一個網(wǎng)絡(luò)和每一臺主機(jī)分配一個邏輯地址，以此來屏蔽物理地址的差異。
其實(shí)覺得沒啥必要單獨(dú)講這個，但是寫到這里了，為了統(tǒng)一格式就這樣吧，所以ip也單獨(dú)列出來了。
TCP/IP協(xié)議
剛剛關(guān)于tcp和IP都單獨(dú)講了?，F(xiàn)在我們就說說這一組協(xié)議。
TCP/IP協(xié)議（傳輸控制協(xié)議/互聯(lián)網(wǎng)協(xié)議）不是簡單的一個協(xié)議，而是一組特別的協(xié)議，包括：TCP，IP，UDP，ARP等，這些被稱為子協(xié)議。在這些協(xié)議中，最重要、最著名的就是TCP和IP。因此，大部分網(wǎng)絡(luò)管理員稱整個協(xié)議族為“TCP/IP”。
————來源百度百科
就是tcp知識一個傳輸?shù)膮f(xié)議。我們平時兩臺電腦上的互相發(fā)送信息，是ip協(xié)議確定哪兩臺電腦，然后tcp協(xié)議來確確實(shí)實(shí)是傳輸數(shù)據(jù)。
TCP的三次握手
額，這個問題我在好幾天的的面經(jīng)里就提過了，不過今天既然總結(jié)到這里了就當(dāng)復(fù)習(xí)，重新說一下。
首先明確一點(diǎn)：每次通信都是客戶端主動連接服務(wù)端的。我們做項(xiàng)目的應(yīng)該能理解這個。Java之所以是后端開發(fā)，人家寫頁面的之所以是前端開發(fā)（我沒任何鄙視的意思，就是一個形象的比喻），就是因?yàn)槊看味际乔岸苏{(diào)用后端的接口，你做過后端主動去調(diào)用前端的啥啥啥？同樣這個道理，服務(wù)器就跟個飯店似的，一直在那開著，客戶端相當(dāng)于客人，想去吃飯可以進(jìn)去，然后點(diǎn)菜。但是不能飯店自己主動做個菜強(qiáng)迫某人買吧？
我先言語上大概敘述一下tcp通信的過程，然后有必要直接貼個圖上來。
我剛剛尋思怎么解釋這個三次握手尋思的我自己都樂的不行。其實(shí)如果你想象力和我一樣豐富的話，會覺得知識里真的好多樂趣。
我大概說一下，tcp建立一個連接需要三次握手，而終止一個連接要經(jīng)過四次揮手，這是由TCP的半關(guān)閉（half-close）造成的。
建立連接：
- 客戶端發(fā)送SYN（SEQ=x）報文給服務(wù)器端，進(jìn)入SYN_SEND狀態(tài)。
（我們可以想象成客戶端給服務(wù)端發(fā)個消息：大哥，聊聊？
這里的SYN，和SYN_SEND狀態(tài)，Established狀態(tài)，有興趣的自己去找找。個人感覺就像數(shù)據(jù)庫常量定義似的，沒啥絕對的意義。） - 服務(wù)器端收到SYN報文，回應(yīng)一個SYN （SEQ=y）ACK（ACK=x+1）報文，進(jìn)入SYN_RECV狀態(tài)。
（服務(wù)端收到客戶端消息了，尋思反正也沒啥事，聊聊就聊聊吧。然后說：行，我是XX，你要是沒找錯人，聊一會兒也行?。?/li> - 客戶端收到服務(wù)器端的SYN報文，回應(yīng)一個ACK（ACK=y+1）報文，進(jìn)入Established狀態(tài)
（客戶端收到服務(wù)端回復(fù)說能聊，回了個字：沒找錯人，就是你。然后這個時候倆人，不對，兩臺電腦就可以開始傳數(shù)據(jù)了。）
其實(shí)咋說呢，我們說的三次握手就是三次數(shù)據(jù)的傳輸（個人理解，我不知道準(zhǔn)不準(zhǔn)確）。就跟你微信跟人聊天似的，
你跟人先說話,給人家發(fā)一條：在么?方便么？我發(fā)語音了啊？(直男第一問候語)。
人家回你：在，有空，發(fā)吧。
你還欠兒欠兒的回了句：那我發(fā)了啊!
然后才開始彈語音。
你看看，這是不是也是三條數(shù)據(jù)？tcp的三次握手我個人感覺就是這樣。
結(jié)束連接：
某個應(yīng)用進(jìn)程首先調(diào)用close，稱該端執(zhí)行“主動關(guān)閉”（active close）。該端的TCP于是發(fā)送一個FIN分節(jié)，表示數(shù)據(jù)發(fā)送完畢。
（繼續(xù)上文，那個片發(fā)出去了，然后你的電腦上顯示發(fā)送完畢了。然后你打字說：發(fā)完了。）接收到這個FIN的對端執(zhí)行 “被動關(guān)閉”（passive close），這個FIN由TCP確認(rèn)。
（接收方也直接下載下來了。回了句：嗯，我也下載完了。）一段時間后，接收到這個文件結(jié)束符的應(yīng)用進(jìn)程將調(diào)用close關(guān)閉它的套接字。這導(dǎo)致它的TCP也發(fā)送一個FIN。
（接收方緊接著又發(fā)了一條消息：謝了啊兄弟，我看電影去了啊，拜拜）接收這個最終FIN的原發(fā)送端TCP（即執(zhí)行主動關(guān)閉的那一端）確認(rèn)這個FIN。
（你這個發(fā)片的看到以后回復(fù)：行，兄弟你忙去吧，注意身體啊，拜拜）
到了這里，你們骯臟的py交易就結(jié)束了。連接也結(jié)束了。再想聯(lián)系又要創(chuàng)建一個新的連接了。然后我上一下正經(jīng)的結(jié)束連接的圖吧。我也不知道我講明白沒有，反正笑得挺歡。腦補(bǔ)是個好東西啊。
然后TCP的三次握手，和工作過程我感覺也就這樣了。好多細(xì)節(jié)之類的想知道自己去查一些權(quán)威資料吧。
HTTP工作過程
最后說一下HTTP的工作流程。
假如你仔細(xì)看了上面的內(nèi)容，應(yīng)該可以直接理解這個圖了。HTTP是一個簡單的請求-響應(yīng)協(xié)議，它通常運(yùn)行在TCP之上。它指定了客戶端可能發(fā)送給服務(wù)器什么樣的消息以及得到什么樣的響應(yīng)。然后下圖是一次完整的數(shù)據(jù)傳送過程。我真的寫不來各種繪圖，所以一般復(fù)雜一點(diǎn)，段落說不清的我直接手繪傳圖了。我盡量寫的字標(biāo)準(zhǔn)一點(diǎn)，起碼能認(rèn)出來。
然后這篇文章就這樣了。有不同意見或者我哪里理解錯了說的有問題的歡迎指出，評論或者私聊都可以。共同交流進(jìn)步嘛！再重申一點(diǎn)?。?！我這些也都是看視頻，看百度百科，查資料啥的，還要加上自己的一些理解，最后寫出來的?？赡苡械牡胤?jīng)]說的很透或者說的很淺薄，但是也就這樣了。反正歡迎指錯。
全文手打不易，如果你覺得對你有幫助請點(diǎn)個喜歡，點(diǎn)個關(guān)注啥的??！
