我所整理的東西都是曾經看視訊，文章，或者某個大佬說的話最後寫成的筆記。現在相當于把筆記重新整理成一篇文章。是以哪怕有一些引用也找不到出處了，就不标明了！
什麼是HTTP協定？
HTTP協定是超文本傳輸協定（預設端口80）。
伺服器傳輸超文本到本地浏覽器的傳送協定。
HTTP是一個基于TCP/IP通信協定來傳送資料的。
HTTP就是客服端→服務端的資料傳輸。
大緻工作流程：
（1）客戶與伺服器建立連接配接；
（2）客戶向伺服器提出請求；
（3）伺服器接受請求，并根據請求傳回相應的檔案作為應答；
（4）客戶與伺服器關閉連接配接。
HTTP的特征：
1. 無連接配接（HTTP 的設計者有意利用這種特點将協定設計為請求時建連接配接、請求完釋放連接配接，以盡快将資源釋放出來服務其他用戶端。）。
正常預設是短連結：建立連接配接→傳送資料→關閉連接配接。
但是随着發展，發現有時候每次通路都需要建立一次 TCP 連接配接就顯得很低效。後來，Keep-Alive 被提出用來解決這效率低的問題。就是長連接配接。
可以設定為長連接配接：建立連接配接→傳送資料→傳送資料→...→關閉連接配接。
其實長連接配接還分為兩種（完全理論知識，我沒實際操作過。視訊裡講的）：
- without pipdining：收到上一個請求響應後才能發下一個。
- with pipdining：不管響沒響應，都可以再發請求。
長短連接配接的優缺點：
像WEB網站的http服務一般都用短連結，因為長連接配接對于服務端來說會耗費一定的資源，而像WEB網站這麼頻繁的成千上萬甚至上億用戶端的連接配接用短連接配接會更省一些資源，如果用長連接配接，而且同時有成千上萬的使用者，如果每個使用者都占用一個連接配接的話，那可想而知吧。是以并發量大，但每個使用者無需頻繁操作情況下需用短連好。
長連接配接是為了節省每次請求都要建立新連接配接所需要的時間，還節約帶寬。多用于操作頻繁，點對點的通訊，而且連接配接數不能太多情況。每個TCP連接配接都需要三步握手，這需要時間，如果每個操作都是先連接配接，再操作的話那麼處理速度會降低很多，是以每個操作完後都不斷開，次處理時直接發送資料包就OK了，不用建立TCP連接配接。例如：資料庫的連接配接用長連接配接， 如果用短連接配接頻繁的通信會造成socket錯誤，而且頻繁的socket 建立也是對資源的浪費。
2. HTTP是媒體獨立的（不同的地方有不同的說法，我這裡按照視訊裡講解的說了。我也在别的地方看到的http特點不是這麼講的，别較真）。
因為tcp傳輸的是封包段，是以任何類型都可以傳輸。隻要用戶端和服務端達成一緻即可。
3. HTTP是無狀态的（這個無連接配接和無狀态是統一說法，沒啥好撕的）。
通俗一點的了解就是：啥也不記。
優缺點都有：缺點是如果需要之前的資料必須重新傳，比較麻煩。但是如果不需要資料則正好，應答較快。
這裡有一點要注意：HTTP 是一個無狀态協定，這意味着每個請求都是獨立的，Keep-Alive 沒能改變這個結果。是以我們所謂的長連接配接隻不過不用每次建立連接配接，但是每一次的請求還是獨立的。
這些就是我之前在視訊裡看到的并且總結的知識點。然後因為寫這篇文章是以還額外找了一些資料。看到了另一種關于http特征的說法，在這裡粘貼一下，文章的最後我會貼上參考連結的。
HTTP協定的主要特點可概括如下：
1.支援客戶/伺服器模式。
2.簡單快速：客戶向伺服器請求服務時，隻需傳送請求方法和路徑。請求方法常用的有GET、HEAD、POST。每種方法規定了客戶與伺服器聯系的類型不同。由于HTTP協定簡單，使得HTTP伺服器的程式規模小，因而通信速度很快。
3.靈活：HTTP允許傳輸任意類型的資料對象。正在傳輸的類型由Content-Type（Content-Type是HTTP包中用來表示内容類型的辨別）加以标記。
4.無連接配接：無連接配接的含義是限制每次連接配接隻處理一個請求。伺服器處理完客戶的請求，并收到客戶的應答後，即斷開連接配接。采用這種方式可以節省傳輸時間。
5.無狀态：HTTP協定是無狀态協定。無狀态是指協定對于事務處理沒有記憶能力。缺少狀态意味着如果後續處理需要前面的資訊，則它必須重傳，這樣可能導緻每次連接配接傳送的資料量增大。另一方面，在伺服器不需要先前資訊時它的應答就較快。
我們通過對比可以發現，其實主要的兩個不改變的就是無狀态，無連接配接。然後這裡的簡單快速和靈活的原因就是因為支援客戶/伺服器模式。也就是媒體獨立。總的來說，大概意思是差不多的。
更多HTTP面試資料、筆記添加微信：YDT939擷取，還有更多java專題面試資料等你來拿！
TCP協定 （傳輸控制協定）
上面說http的時候一直有提到tcp協定。這裡專門講一下什麼是tcp協定：
傳輸控制協定（TCP，Transmission Control Protocol）是為了在不可靠的網際網路絡上提供可靠的端到端位元組流而專門設計的一個傳輸協定。
這個是百度百科的介紹。其實很好了解。為了端到端的資料傳輸而專門設計的。
用一個我個人的想象的了解：旅行箱/書包/塑膠袋是為了我們在一個地方到另一個地方的攜帶/運輸而設計的。如果我從超市買一大堆東西，沒有任何包裝工具（袋子，箱子，盒子啥的），一起在懷裡捧着，可能到家會發現半路上丢了東西。本來想吃火鍋，啥都買好了捧到家發現火鍋料丢了。完了，整個計劃都不能實作了。
同樣的道理，兩個端資料傳輸，我們起碼得保證傳送的和接受的要一樣吧？不然一會兒丢個位元組，一會兒丢個段落，最後傳過去的東西接收方都看不明白，那還有什麼意義了？由此，tcp就是這麼一個保證檔案傳輸過程中不會丢減位元組的協定。
接下來我直接貼上百度百科對tcp的介紹，有空的同學可以看一下，不太複雜。
TCP是一種面向廣域網的通信協定，目的是在跨越多個網絡通信時，為兩個通信端點之間提供一條具有下列特點的通信方式： [1]
（1）基于流的方式；
（2）面向連接配接；
（3）可靠通信方式；
（4）在網絡狀況不佳的時候盡量降低系統由于重傳帶來的帶寬開銷；
（5）通信連接配接維護是面向通信的兩個端點的，而不考慮中間網段和節點。
為滿足TCP協定的這些特點，TCP協定做了如下的規定： [10]
①資料分片：在發送端對使用者資料進行分片，在接收端進行重組，由TCP确定分片的大小并控制分片和重組；
②到達确認：接收端接收到分片資料時，根據分片資料序号向發送端發送一個确認；
③逾時重發：發送方在發送分片時啟動逾時定時器，如果在定時器逾時之後沒有收到相應的确認，重發分片；
④滑動視窗：TCP連接配接每一方的接收緩沖空間大小都固定，接收端隻允許另一端發送接收端緩沖區所能接納的資料，TCP在滑動視窗的基礎上提供流量控制，防止較快主機緻使較慢主機的緩沖區溢出；
⑤失序處理：作為IP資料報來傳輸的TCP分片到達時可能會失序，TCP将對收到的資料進行重新排序，将收到的資料以正确的順序交給應用層；
⑥重複處理：作為IP資料報來傳輸的TCP分片會發生重複，TCP的接收端必須丢棄重複的資料；
⑦資料校驗：TCP将保持它首部和資料的檢驗和，這是一個端到端的檢驗和，目的是檢測資料在傳輸過程中的任何變化。如果收到分片的檢驗和有差錯，TCP将丢棄這個分片，并不确認收到此封包段導緻對端逾時并重發。
上面的通信方式讓我們對tcp有一個更清晰的認識。
下面的規定都是為了保證傳遞過程中資料不會變。保證發送的和接受的是一樣一樣的東西。（就好像塑膠袋的作用是裝進袋子裡的東西和到家以後從袋子裡拿出來的東西是一樣的。别跟我說什麼袋子壞掉了，路上偷吃了什麼的情況啊！！！）然後我覺得概念還好了解。而且做法也通俗易懂的。一會兒下面還會有提到。
IP
IP位址是IP協定提供的一種統一的位址格式，它為網際網路上的每一個網絡和每一台主機配置設定一個邏輯位址，以此來屏蔽實體位址的差異。
其實覺得沒啥必要單獨講這個，但是寫到這裡了，為了統一格式就這樣吧，是以ip也單獨列出來了。
TCP/IP協定
剛剛關于tcp和IP都單獨講了。現在我們就說說這一組協定。
TCP/IP協定（傳輸控制協定/網際網路協定）不是簡單的一個協定，而是一組特别的協定，包括：TCP，IP，UDP，ARP等，這些被稱為子協定。在這些協定中，最重要、最著名的就是TCP和IP。是以，大部分網絡管理者稱整個協定族為“TCP/IP”。
————來源百度百科
就是tcp知識一個傳輸的協定。我們平時兩台電腦上的互相發送資訊，是ip協定确定哪兩台電腦，然後tcp協定來确确實實是傳輸資料。
TCP的三次握手
額，這個問題我在好幾天的的面經裡就提過了，不過今天既然總結到這裡了就當複習，重新說一下。
首先明确一點：每次通信都是用戶端主動連接配接服務端的。我們做項目的應該能了解這個。Java之是以是後端開發，人家寫頁面的之是以是前端開發（我沒任何鄙視的意思，就是一個形象的比喻），就是因為每次都是前端調用後端的接口，你做過後端主動去調用前端的啥啥啥？同樣這個道理，伺服器就跟個飯店似的，一直在那開着，用戶端相當于客人，想去吃飯可以進去，然後點菜。但是不能飯店自己主動做個菜強迫某人買吧？
我先言語上大概叙述一下tcp通信的過程，然後有必要直接貼個圖上來。
我剛剛尋思怎麼解釋這個三次握手尋思的我自己都樂的不行。其實如果你想象力和我一樣豐富的話，會覺得知識裡真的好多樂趣。
我大概說一下，tcp建立一個連接配接需要三次握手，而終止一個連接配接要經過四次揮手，這是由TCP的半關閉（half-close）造成的。
建立連接配接：
-
用戶端發送SYN（SEQ=x）封包給伺服器端，進入SYN_SEND狀态。
（我們可以想象成用戶端給服務端發個消息：大哥，聊聊？
這裡的SYN，和SYN_SEND狀态，Established狀态，有興趣的自己去找找。個人感覺就像資料庫常量定義似的，沒啥絕對的意義。）
-
伺服器端收到SYN封包，回應一個SYN （SEQ=y）ACK（ACK=x+1）封包，進入SYN_RECV狀态。
（服務端收到用戶端消息了，尋思反正也沒啥事，聊聊就聊聊吧。然後說：行，我是XX，你要是沒找錯人，聊一會兒也行！）
-
用戶端收到伺服器端的SYN封包，回應一個ACK（ACK=y+1）封包，進入Established狀态
（用戶端收到服務端回複說能聊，回了個字：沒找錯人，就是你。然後這個時候倆人，不對，兩台電腦就可以開始傳資料了。）
其實咋說呢，我們說的三次握手就是三次資料的傳輸（個人了解，我不知道準不準确）。就跟你微信跟人聊天似的，
你跟人先說話,給人家發一條：在麼?友善麼？我發語音了啊？(直男第一問候語)。
人家回你：在，有空，發吧。
你還欠兒欠兒的回了句：那我發了啊!
然後才開始彈語音。
你看看，這是不是也是三條資料？tcp的三次握手我個人感覺就是這樣。
三次握手圖解
更多HTTP面試資料、筆記添加微信：YDT939擷取，還有更多java專題面試資料等你來拿！
結束連接配接：
-
某個應用程序首先調用close，稱該端執行“主動關閉”（active close）。該端的TCP于是發送一個FIN分節，表示資料發送完畢。
（繼續上文，那個片發出去了，然後你的電腦上顯示發送完畢了。然後你打字說：發完了。）
-
接收到這個FIN的對端執行 “被動關閉”（passive close），這個FIN由TCP确認。
（接收方也直接下載下傳下來了。回了句：嗯，我也下載下傳完了。）
-
一段時間後，接收到這個檔案結束符的應用程序将調用close關閉它的套接字。這導緻它的TCP也發送一個FIN。
（接收方緊接着又發了一條消息：謝了啊兄弟，我看電影去了啊，拜拜）
-
接收這個最終FIN的原發送端TCP（即執行主動關閉的那一端）确認這個FIN。
（你這個發片的看到以後回複：行，兄弟你忙去吧，注意身體啊，拜拜）
到了這裡，你們肮髒的py交易就結束了。連接配接也結束了。再想聯系又要建立一個新的連接配接了。然後我上一下正經的結束連接配接的圖吧。我也不知道我講明白沒有，反正笑得挺歡。腦補是個好東西啊。
tcp連接配接的終止
然後TCP的三次握手，和工作過程我感覺也就這樣了。好多細節之類的想知道自己去查一些權威資料吧。
HTTP工作過程
最後說一下HTTP的工作流程。
假如你仔細看了上面的内容，應該可以直接了解這個圖了。HTTP是一個簡單的請求-響應協定，它通常運作在TCP之上。它指定了用戶端可能發送給伺服器什麼樣的消息以及得到什麼樣的響應。然後下圖是一次完整的資料傳送過程。我真的寫不來各種繪圖，是以一般複雜一點，段落說不清的我直接手繪傳圖了。我盡量寫的字标準一點，起碼能認出來。
http工作過程
然後這篇文章就這樣了。有不同意見或者我哪裡了解錯了說的有問題的歡迎指出，評論或者私聊都可以。共同交流進步嘛！再重申一點！！！我這些也都是看視訊，看百度百科，查資料啥的，還要加上自己的一些了解，最後寫出來的。可能有的地方沒說的很透或者說的很淺薄，歡迎指錯。
HTTP超全思維導圖：