计算机网络面试问题总结
計算機網絡
- I/O復用
- 12.五種IO復用
- 13.Reactor和Proactor
- 14.epoll如何判斷數據已經讀取完成
- 1.select poll 和epoll的原理以及最大區別
- 2.什么是IO復用
- 3.阻塞 I/O 和非阻塞 I/O,具體是怎么樣的
- 1.阻塞I/O
- 2.非阻塞IO模型
- 5.epoll為什么ctrl和wait分開
- 6.公網和私網IP如何轉換
- 7.epoll反應堆模型
- 8.ping命令的原理
- 9.socket的阻塞模式與非阻塞模式
- 10.ET模式與LT模式
- 11.htonl函數
- TCP/IP協議
- 4.鍵入www.baidu.com后發生的全過程
- 5.2MSL
- 6.TCP三次握手四次揮手流程
- 1.三次握手建立連接流程
- 2.四次揮手流程
- 7.TCP十種狀態
- 8.TCP各個標志位的意義
- 9.三次握手必要性
- 10.三次握手出錯的處理方法
- 11.四次揮手必要性
- 12.TCP長連接，短連接
- 13.TCP如何重連接
- 14.TCP如何保證可靠傳輸
- 15.TCP為什么會有多個CLOSE_WAIT狀態
- 16.TCP有大量TIME_WAIT的原因
- 17.OSI七層協議及其作用
- 18.TCP/IP協議
- 19.TCP/IP四層網絡模型
- 21.TCP的沾包問題
- 22.MTU
- 23.socket編寫TCP協議的流程
- 24.ARP協議原理
- 25.DNS解析過程
- 26.1 TCP與UDP的優缺點
- 26.TCP/UDP的區別
- 26.UDP如何保證可靠傳輸
- UDP改進網絡---UDT
- 27.TCP協議：reset
- 28.如何通過局域網獲得另一臺電腦的一個文件
- 29.ARQ協議
- 30.TCP的滑動窗口
- 31. TCP的保活機制
- 32.socket編程中TCP三次握手
- 33.UDP如何實現一對多
- 34.TCP/IP模型各層的網絡攻擊
- 35.TIME_WAIT過多
- 36.TIME_WAIT過多如何排查
- 37.CLOSE_WAIT產生的原因及解決
- 38.數據包從一個主機發送到另一個主機
- 39.IPV6和IPV4
- 40.TCP超時重傳的次數限制
- HTTP
- 1.HTTP/HTTPS
- 1.HTTP詳解
- 2.對稱加密和非對稱加密
- 3.HTTPS的握手方式
- 4.XSS攻擊：
- 5.GET方法與POST方法的區別
- 9.云計算
- 10.https如何保證公鑰可信性
- 11.HTTP2.0
- 12.HTTP1.1和HTTP2.0的區別
- 13.HTTP狀態碼301 與 302的區別
- 14. HTTP狀態？Cookie 和 Session
I/O復用
12.五種IO復用
參考>>
13.Reactor和Proactor
參考>>
Reactor模型
mainReactor負責監聽server socket，用來處理新連接的建立，將建立的socketChannel指定注冊給subReactor。
subReactor維護自己的selector, 基于mainReactor 注冊的socketChannel多路分離IO讀寫事件，讀寫網 絡數據，對業務處理的功能，另其扔給worker線程池來完成。
我們可以看到，mainReactor 主要是用來處理網絡IO 連接建立操作，通常一個線程就可以處理，而subReactor主要做和建立起來的socket做數據交互和事件業務處理操作，它的個數上一般是和CPU個數等同，每個subReactor一個縣城來處理。
[參考文章>>>>>>>>>>>>>>>>>>>>>>>>]
兩者的區別：
在Reactor模式中，事件分離者等待某個事件或者可應用或個操作的狀態發生（比如文件描述符可讀寫，或者是socket可讀寫），事件分離器就把這個事件傳給事先注冊的處理器（事件處理函數或者回調函數），由后者來做實際的讀寫操作。
在Proactor模式中，事件處理者(或者代由事件分離者發起)直接發起一個異步讀寫操作(相當于請求)，而實際的工作是由操作系統來完成的。發起時，需要提供的參數包括用于存放讀到數據的緩存區，讀的數據大小，或者用于存放外發數據的緩存區，以及這個請求完后的回調函數等信息。事件分離者得知了這個請求，它默默等待這個請求的完成，然后轉發完成事件給相應的事件處理者或者回調。
可以看出兩者的區別：Reactor是在事件發生時就通知事先注冊的事件（讀寫由處理函數完成）；Proactor是在事件發生時進行異步I/O（讀寫由OS完成），待IO完成事件分離器才調度處理器來處理。
14.epoll如何判斷數據已經讀取完成
=====>
只有在使用epoll ET(Edge Trigger)模式的時候，才需要關注數據是否讀取完畢了。使用select或者epoll的LT模式，其實根本不用關注數據是否讀完了，select/epoll檢測到有數據可讀去讀就OK了。
兩種做法：
1、針對TCP，調用recv方法，根據recv的返回值。如果返回值小于我們設定的recv buff的大小，那么就認為接收完畢。
2、TCP、UDP都適用，將socket設為NOBLOCK狀態（使用fcntl函數），然后select該socket可讀的時候，使用read/recv函數讀取數據。當返回值為-1，并且errno是EAGAIN或EWOULDBLOCK的時候，表示數據讀取完畢。
1.select poll 和epoll的原理以及最大區別
參考文章>>
select原理：，需要一個fd_set 集合來記錄每個連接的文件描述符，該集合使用位圖的方式，每一位都表示一個文件描述符，1表示已連接，0表示為連接，將fd_set 拷貝一份后傳入內核，由內核對fd_set 內進行輪詢檢測，將fd_set 中已連接但未就緒的文件描述符置為0，返回文件描述符集合，然后在用戶態中對fd_set 中的連接進行通信。用戶態下還需要對fd_set集合進行輪詢。
poll原理：也需要進行由用戶態到內核態下數據的拷貝，與select不同，poll直接將要檢測的文件描述符的信息封裝到結構體struct pollfd中，用戶態和內核態下都可直接讀寫結構體變量。結構體中存儲著文件描述符，委托內核檢測的事件，以及該文件描述符實際發生的事件。內核檢測到事件后改寫這個事件，如何沒檢測到任何事件，則將這個結構體的文件描述符置為-1。
epoll原理：首先通過epoll_create()。同時會創建一個event_poll結構體，結構體中存儲著一顆紅黑樹的根節點，每次有連接，通過epoll_ctrl()函數就會將連接的文件描述符放入紅紅黑樹中，該紅黑樹一直維護在內核中，這是因為紅黑樹查找插入刪除的效率都比較高。同時該結構體中還存儲一個雙向鏈表，當某個文件描述符有事件發生時，會調用自身的回調函數，將該節點的信息存儲在鏈表中，該鏈表存儲著已經準備就緒的文件描述符信息。當用戶態下調用epoll_wait()函數時，內核直接檢測該雙向鏈表中是否有元素存在，有元素就將發生的事件拷貝到用戶態。
epoll會為每個連接創建一個epoll_event結構體
epoll_event中有一個聯合體，通常用該聯合體的int類型的fd，還有一個數據表示事件類型，調用epoll_wait后，內核會幫助檢測每個連接的是否就緒，是否就緒事件是被用戶委托檢測的事件，然后將合適的連接同樣保存到epoll_event evs結構體數組中，供用戶態使用。
struct eventpoll{..../*紅黑樹的根節點，這顆樹中存儲著所有添加到epoll中的需要監控的事件*/struct rb_root rbr;/*雙鏈表中則存放著將要通過epoll_wait返回給用戶的滿足條件的事件*/struct list_head rdlist;.... };區別：
- 1.是否跨平臺：
select可以跨平臺，poll和epoll不可以 - 2.是否有最大連接數限制
select最大1024，poll和epoll沒有 - 3.如何查詢描述符狀態
select和poll采用遍歷輪詢，epoll不輪詢，采用回調機制，事件驅動。 - 4.是否在用戶態和內核態之間拷貝檢測集合
select和poll每次調用都會拷貝文件描述符集合，epoll中每個文件描述符只在注冊時拷貝一次。注：select往內核拷貝檢測集合的副本，poll往內核拷貝檢測集合原集合。
最大區別：
1.查詢文件描述符的狀態，select和poll采用輪詢；epoll采用回調機制，是事件驅動的，就緒的設備會自動將文件描述符添加到就緒鏈表中。
2.select/poll 低效的原因之一是將 “添加 / 維護待檢測任務” 和 “阻塞進程 / 線程” 兩個步驟合二為一。每次調用 select 都需要這兩步操作，然而大多數應用場景中，需要監視的 socket 個數相對固定，并不需要每次都修改。epoll 將這兩個操作分開，先用 epoll_ctl() 維護等待隊列，再調用 epoll_wait() 阻塞進程（解耦）。
參考文章>>
形象的參考文章>>
2.什么是IO復用
形象參考文章>>
概念1 ：什么是文件
實際上所有的I/O設備都被抽象為了文件這個概念，一切皆文件，Everything is File，磁盤、網絡數據、終端，甚至進程間通信工具管道pipe等都被當做文件對待。
概念2：什么是文件描述符
在Linux世界要想使用文件，我們也需要借助一個號碼，這個號碼就、被稱為了文件描述符，file descriptors。文件描述僅僅就是一個數字而已，但是通過這個數字我們可以操作一個打開的文件。
有了文件描述符，進程可以對文件一無所知，比如文件在磁盤的什么位置、加載到內存中又是怎樣管理的等等，這些信息統統交由操作系統打理，進程無需關心，操作系統只需要給進程一個文件描述符就足夠了。
關于IO復用：
在網絡編程中，當連接個數比較少時，借助accept即可獲得一個文件描述符，但是當出現大量連接時，我們不能每次只獲取一個連接然后進行通信，需要將已就緒的文件描述符全部獲取然后通信，這時候就需要IO復用，即一次可以處理多路IO。
I/O多路復用，I/O multiplexing，multiplexing一詞其實多用于通信領域，為了充分利用通信線路，希望在一個信道中傳輸多路信號，要想在一個信道中傳輸多路信號就需要把這多路信號結合為一路，將多路信號組合成一個信號的設備被稱為multiplexer，顯然接收方接收到這一路組合后的信號后要恢復原先的多路信號，這個設備被稱為demultiplexer，如圖所示：
所以I/O多路復用指的是這樣一個過程：
通俗：IO 多路轉接的意思是在一個操作里同時監聽多個輸入輸出源，在其中一個或多個輸入輸出源可用的時候返回，然后對其的進行讀寫操作。
三大IO復用機制：
select
poll
epoll
3.阻塞 I/O 和非阻塞 I/O,具體是怎么樣的
1.阻塞I/O
進程發起IO系統調用后，進程被阻塞，轉到內核空間處理，整個IO處理完畢后返回進程。操作成功則進程獲取到數據。
典型應用：
阻塞socket
特點：
-
進程阻塞掛起不消耗CPU資源，及時響應每個操作；
-
實現難度低、開發應用較容易；
-
適用并發量小的網絡應用開發；
-
不適用并發量大的應用：因為一個請求IO會阻塞進程（線程），所以，得為每請求分配一個處理進程（線程）以及時響應，系統開銷大。
2.非阻塞IO模型
進程發起IO系統調用后，如果內核緩沖區沒有數據，需要到IO設備中讀取，進程返回一個錯誤而不會被阻塞；進程發起IO系統調用后，如果內核緩沖區有數據，內核就會把數據返回進程。
對于上面的阻塞IO模型來說，內核數據沒準備好需要進程阻塞的時候，就返回一個錯誤，以使得進程不被阻塞。
典型應用：
socket是非阻塞的方式（設置為NONBLOCK）
特點：
-
進程輪詢（重復）調用，消耗CPU的資源；
-
實現難度低、開發應用相對阻塞IO模式較難；
-
適用并發量較小、且不需要及時響應的網絡應用開發；
5.epoll為什么ctrl和wait分開
參考文章>>
select/poll 低效的原因之一是將 “添加 / 維護待檢測任務” 和 “阻塞進程 / 線程” 兩個步驟合二為一。每次調用 select 都需要這兩步操作，然而大多數應用場景中，需要監視的 socket 個數相對固定，并不需要每次都修改。epoll 將這兩個操作分開，先用 epoll_ctl() 維護等待隊列，再調用 epoll_wait() 阻塞進程（解耦）。
6.公網和私網IP如何轉換
7.epoll反應堆模型
參考文章>>
1.傳統的epoll服務器模型
監聽可讀事件(ET) ? 數據到來? 觸發讀事件 ?epoll_wait()返回 ?read消息 ? write回射信息 ? 繼續epoll_wait()? 直到程序停止前都是這么循環。
2.epoll反應堆服務器模型
監聽可讀事件(ET) ? 數據到來 ? 觸發讀事件?epoll_wait()返回 ?read完數據; 節點下樹; 設置監聽寫事件和對應寫回調函數; 節點上樹(可讀事件回調函數內)? 監聽可寫事件(ET) ? 對方可讀 ? 觸發事件 ?epoll_wait()返回 ?write數據; 節點下樹; 設置監聽讀事件和對應可讀回調函數; 節點上樹(可寫事件回調函數內)? 直到程序停止前一直這么交替循環。
原因：
為什么要可讀以后設置可寫？然后一直交替？
服務器向客戶端write數據，并不一定能write成功，原因有二
(1) 滑動窗口機制：
服務器向客戶端write數據，假設剛好此時客戶端的接收滑動窗口滿，將導致當前服務器將阻塞在send函數處，導致服務器程序阻塞。
解決方案：設置可寫事件，當客戶端的接收緩沖區有空閑時，將導致該socket可寫，在可寫回調函數中調用send函數
(2) SIGPIPE信號：
客戶端send完數據后，突然由于異常停止，這將導致一個FIN發送給服務器。如果服務器不設置可寫事件監聽，那么服務器在read完數據后，直接向沒有讀端的套接字中寫入數據，TCP協議棧將會給服務器發送RST分節+SIGPIPE信號，導致服務器進程終止。
8.ping命令的原理
簡單來說，「ping」是用來探測本機與網絡中另一主機之間是否可達的命令，如果兩臺主機之間ping不通，則表明這兩臺主機不能建立起連接。ping是定位網絡通不通的一個重要手段。
ping 命令是基于 ICMP 協議來工作的，「 ICMP 」全稱為 Internet 控制報文協議（ Internet Control Message Protocol）。ping 命令會發送一份ICMP回顯請求報文給目標主機，并等待目標主機返回ICMP回顯應答。因為ICMP協議會要求目標主機在收到消息之后，必須返回ICMP應答消息給源主機，如果源主機在一定時間內收到了目標主機的應答，則表明兩臺主機之間網絡是可達的。
9.socket的阻塞模式與非阻塞模式
參考文章>>
Windows套接字在阻塞和非阻塞兩種模式下執行I/O操作。在阻塞模式下，在I/O操作完成前，執行的操作函數一直等候而不會立即返回，該函數所在的線程會阻塞在這里。相反，在非阻塞模式下，套接字函數會立即返回，而不管I/O是否完成，該函數所在的線程會繼續運行。
阻塞模式下：
bind()、listen()函數時，函數會立即返回。
recv()、recvfrom()、WSARecv()和WSARecvfrom()函數。以阻塞套接字為參數調用該函數接收數據。如果此時套接字緩沖區內沒有數據可讀，則調用線程在數據到來前一直睡眠。
send()、sendto()、WSASend()和WSASendto()函數。以阻塞套接字為參數調用該函數發送數據。如果套接字緩沖區沒有可用空間，線程會一直睡眠，直到有空間。
accept()和WSAAcept()函數。以阻塞套接字為參數調用該函數，等待接受對方的連接請求。如果此時沒有連接請求，線程就會進入睡眠狀態。
connect()和WSAConnect()函數。對于TCP連接，客戶端以阻塞套接字為參數，調用該函數向服務器發起連接。該函數在收到服務器的應答前，不會返回。這意味著TCP連接總會等待至少到服務器的一次往返時間。
非阻塞模式下：
套接字設置為非阻塞模式后，在調用API函數時，調用函數會立即返回。大多數情況下，這些函數調用都會調用“失敗”，并返回錯誤代碼，bind()函數時不會返回錯誤代碼。
10.ET模式與LT模式
參考文章>>
LT 和 ET本質的區別是：
LT模式狀態時，主線程正在epoll_wait等待事件時，請求到了，epoll_wait返回后沒有去處理請求(recv)，那么下次epoll_wait時此請求還是會返回（立刻返回了）；而ET模式狀態下，這次沒處理，下次epoll_wait時將不返回（所以我們應該每次一定要處理），可見很大程度降低了epoll的觸發次數（記住這句話先）。
11.htonl函數
====>>>>
將小端存儲模式轉換為大端存儲模式：
大端（存儲）模式，是指數據的低位保存在內存的高地址中，而數據的高位保存在內存的低地址中
小端（存儲）模式，是指數據的低位保存在內存的低地址中，而數據的高位保存在內存的高地址中
大端（存儲）模式，是指數據的低位保存在內存的高地址中，而數據的高位保存在內存的低地址中
小端（存儲）模式，是指數據的低位保存在內存的低地址中，而數據的高位保存在內存的高地址中
存在原因：
每個地址單元都是以字節為單位，即8位，當所需存儲的數據大于1字節時，就存在一個存儲順序的問題，因此就有了大小端的問題。
計算機內小端字節序：計算機電路先處理低位字節，效率比較高，因為計算都是從低位開始的，所以，計算機的內部處理都是小端字節序。
外部使用大端字節序：人類還是習慣讀寫大端字節序，所以，除了計算機的內部處理，其他的場合幾乎都是大端字節序，比如網絡傳輸和文件儲存。
總結：大端模式就是數據從高字節到低字節在內存中排列，小端模式就是數據從低字節到高字節在內存中排列，數據本身字節是高字節在左，低字節在右。（如二進制8421）。
大小端檢測方法：
原理：由于數據對齊的原因，地址的增長方向是由小變大，c是1字節，i是四字節，聯合體公用一塊內存。在這里就是共用4字節的內存。c放在最開始的第一個字節，如果數據時小端存儲，則1應該在c的位置，如果是大端存儲，則c的位置上放的是0。
htonl、ntohl、htons、ntohs函數實現
TCP/IP協議
4.鍵入www.baidu.com后發生的全過程
參考文章>>
參考文章>>
1.DNS將域名解析為IP地址：DNS解析過程
2.瀏覽器與目標服務器建立TCP連接：三次握手過程，第三次握手時發送請求
3.瀏覽器通過http協議發送請求
4.服務器處理請求
5.服務器發出一個HTML響應
6.釋放TCP連接
7.瀏覽器顯示頁面
5.2MSL
參考文章>>
原因一：客戶端進行第四次揮手ACK后，啟動2MSL計時，ACK+seq+ack最多在1MSL就能到達服務端，如果在1MSL沒到達服務端，服務端會再次重傳FIN+seq+ack+ACK，到達客戶端最多耗時1MSL，客戶端收到重傳的FIN，會再次發送ACK，并啟動2MSL計時器。
原因二：如果不等待這個2MSL而是立即關閉，服務端端口自由，與新的客戶端發生了新的連接，如果服務端沒有收到上個客戶端的第四次揮手的ACK,或者由于網絡中的路由器重復發送FIN報文，會導致剛產生的新連接被關閉，產生誤關閉；或者FIN并沒被重發，而是重復發了其他數據，會導致新連接數據錯亂。所有2MSL可以使本次連接持續的時間內所產生的所有報文段都從網絡中消失。
6.TCP三次握手四次揮手流程
三次握手四次揮手問題匯總：參考文章>>
1.三次握手建立連接流程
三次握手流程：
（1）第一次握手：建立連接時，客戶端A發送SYN包（seq=j，SYN標志位=1）到服務器B，并進入SYN_SEND狀態，等待服務器B確認。
（2）第二次握手：服務器B收到SYN包，必須確認客戶A的SYN（ack=j+1及ACK應答），同時自己也發送一個SYN包（seq=k，SYN標志位 = 1），即SYN+ACK包，此時服務器B進入SYN_RECV狀態。
（3）第三次握手：客戶端A收到服務器B的SYN＋ACK包，向服務器B發送確認包ACK（seq= j+1,ack=k+1,ACK 應答），此包發送完畢，客戶端A和服務器B進入ESTABLISHED狀態，完成三次握手。
2.四次揮手流程
流程：
（1）第一次揮手：客戶端主動發送FIN釋放連接請求、seq = u序號到服務器，請求停止發送數據，進入FIN_WAIT_1（終止等待1），處于一種半關閉狀態。
（2）第二次揮手：服務端發送ACK應答及ack =u+1 ，以及seq = v，B進入CLOS_WAIT(等待關閉)，客戶端到服務端這個方向的連接就關閉了。但客戶端還可以接收。客戶端收到來自服務端的確認ACK，進入FIN_WAIT_2（終止等待2），等待服務端發送釋放連接報文。
（3）服務端發送FIN釋放連接請求，ACK應答，seq = w（中間又有數據傳輸），ack= u+1,服務端進入LAST_ACK（最后確認狀態）。
（4）客戶端發送ACK應答，seq=u+1,ack=w+1到服務端，進入FIN_WAIT(最終等待)，等待2MSL后關閉。
客戶端：主動連接，主動關閉：
主動發起連接請求—>另一端響應請求————>建立連接狀態————>傳輸數據—————>發起關閉請求————>半連接狀態——>另一端響應請求—>另一端發起關閉請求————>本端響應請求———>等待2MSL————>關閉狀態。
服務端：被動連接，被動關閉：
被動接受連接請求————>建立連接狀態————>傳輸數據————>被動接受關閉請求————>等待關閉狀態（等待剩余數據發送完成）————>發起關閉請求————>接收到對方ACK——>關閉。
7.TCP十種狀態
LISTEN - 偵聽來自遠方TCP端口的連接請求； SYN-SENT -在發送連接請求后等待匹配的連接請求； SYN-RECEIVED - 在收到和發送一個連接請求后等待對連接請求的確認； ESTABLISHED- 代表一個打開的連接，數據可以傳送給用戶； FIN-WAIT-1 - 等待遠程TCP的連接中斷請求，或先前的連接中斷請求的確認； FIN-WAIT-2 - 從遠程TCP等待連接中斷請求； CLOSE-WAIT - 等待從本地用戶發來的連接中斷請求； CLOSING -等待遠程TCP對連接中斷的確認； LAST-ACK - 等待原來發向遠程TCP的連接中斷請求的確認； TIME-WAIT -等待足夠的時間以確保遠程TCP接收到連接中斷請求的確認； CLOSED - 沒有任何連接狀態；8.TCP各個標志位的意義
位碼即tcp標志位,有6種標示:1.SYN(synchronous建立聯機)2.ACK(acknowledgement 確認)3.PSH(push傳送)4.FIN(finish結束)5.RST(reset重置)6.URG(urgent緊急)需要發送的號碼： Sequence number(順序號碼)Acknowledge number(確認號碼)9.三次握手必要性
參考文章>>
確保能成功連接
1.假如一次握手
首先tcp是面向連接，一次握手肯定建立不了連接，因為客戶機給服務器發出請求信息卻沒有得到回應，客戶機是沒法判定是否發送成功然后建立連接的。
2.假如兩次握手
假設只有兩次握手，比如圖中的1，2步，當A想要建立連接時發送一個SYN，然后等待ACK，結果這個SYN因為網絡問題沒有及時到達B，所以A在一段時間內沒收到ACK后，再發送第二個SYN，這次B順利收到第二個請求，接著A也收到B發送來的ACK，這時A發送的第一個SYN經過一段時間也到了B，對于B來說這是一個新連接請求，然后B又為這個連接申請資源，返回ACK，然而這個SYN是個無效的請求，A只會承認它最后發的那個SYN的SYN+ACK，A收到B發來的第二個ACK實際是回應A的第一個SYN，所以A并不會理會它，而B卻不知道，B會一直為這個連接維持著資源，造成資源的浪費。
3.假如三次握手
兩次握手的問題在于服務器端不知道一個SYN是否是無效的，而三次握手機制因為客戶端會給服務器回復第二次握手，也意味著服務器會等待客戶端的第三次握手，與兩次握手不同的是，服務器可以通過第三次握手來確認第一個連接請求是否有效，如果第三次握手遲遲不來，服務器便會認為這個SYN是無效的，釋放相關資源。但這時有個問題就是客戶端完成第二次握手便認為連接已建立，而第三次握手可能在傳輸中丟失，服務端會認為連接是無效的，這時如果Client端向Server寫數據，Server端將以RST包響應，這時便感知到發生了錯誤。
10.三次握手出錯的處理方法
11.四次揮手必要性
這是因為TCP半關閉造成的。由于一個TCP連接是全雙工的，在兩個方向上都能傳輸數據，因此兩個方向就需要單獨關閉。
參考文章>>
12.TCP長連接，短連接
長連接：在基于tcp的通訊中，一直保持連接，不管當前是否發送或者接收數據。多用于操作頻繁，點對點的通訊，而且連接數不能太多的情況。
短連接：在有數據傳輸的時候才進行連接，客戶－服務器通信/傳輸數據完畢就關閉連接。
web網站的http服務一般都用短連接。
參考文章>>
在HTTP/1.0中，默認使用的是短連接。也就是說，瀏覽器和服務器每進行一次HTTP操作，就建立一次連接，但任務結束就中斷連接。
但從 HTTP/1.1起，默認使用長連接，用以保持連接特性。使用長連接的HTTP協議，會在響應頭有加入這行代碼：
Connection:keep-alive在使用長連接的情況下，當一個網頁打開完成后，客戶端和服務器之間用于傳輸HTTP數據的 TCP連接不會關閉，如果客戶端再次訪問這個服務器上的網頁，會繼續使用這一條已經建立的連接。Keep-Alive不會永久保持連接，它有一個保持時間，可以在不同的服務器軟件（如Apache）中設定這個時間。實現長連接要客戶端和服務端都支持長連接。
== HTTP協議的長連接和短連接，實質上是TCP協議的長連接和短連接== 。
什么時候長連接，什么時候短連接：
對于操作比較頻繁的，連接數不多的情況下，使用長連接，可以對連接進行復用，節省資源。
對于操作不是很頻繁情況下，連接數目比較多的情況下，使用短連接會比較好，因為服務器的可用連接數目是有限的，如果在這種情況下每個用戶都占用一個連接的話，服務區早晚會撐不住。
13.TCP如何重連接
14.TCP如何保證可靠傳輸
參考文章>>
TCP通過七種方式保證可靠傳輸：
- 1.數據校驗和：接收方對報文經計算后得到的校驗和與發送方發送的校驗和做對比，錯誤則說明傳輸一定有誤，但是正確不一定能保證發送成功。
- 2.確認應答：接收方每次成功接收到數據后，會發送一個ACK應答，告訴發送方這段數據接收成功。
- 3.序列號：TCP每次傳輸都對數據進行了編號，這就是序列號，TCP傳輸的過稱中，每次接收到數據后，都會對傳輸方進行ACK確認應答，應答報文中帶有對應的確認序列號，告訴發送方，接收到了哪些數據，下一次的數據從哪里開始發。序列號還有去重復的功能。
- 4.超時重傳：如果發送方發送的數據由于網絡原因未到接收方，發送方等待一段時間還未接受到ACK應答則重新發送數據；如果發送方發送的數據已經被接收方接收到，但接收方發送的ACK應答丟包，則發送方還是會多次發送數據，接收方終有一次接收到了數據，根據序列號判斷接收的數據已經存在，也直接丟棄報文，并發送ACK應答報文。
超時重傳的時間：太短會導致報文頻繁重發，太長則導致TCP效率下降。
方法：對于同一個報文，取一個固定時長如500ms，每重傳一次等待時間指數倍增長，嘗試指定次數還未接收到數據則關閉連接。 - 5.連接管理：即TCP三次握手四次揮手
- 6.流量控制：TCP根據接收端對數據的處理能力，決定發送端的發送速度，這個機制就是流量控制。接收端會在發送ACK應答報文的時候，將自己接收緩沖區的剩余大小一并發送給發送端，稱為窗口大小，發送端根據這個數據大小來調整自己每次發送速度。如果接收方緩沖區為0，則發送方停止發送，并每隔一段時間發送窗口探測報文，獲取接收方剩余緩存大小。
- 7.擁塞控制：為了保證在不知道網絡擁堵程度的情況下，數據能夠正確傳輸，不被丟包，TCP創建了慢啟動機制，即在剛建立連接后發送方的發送速度由慢變快。避免一建立連接就發送大量數據，如果網絡不好則會導致大量數據重傳，嚴重影響效率。同時引入了擁塞窗口的概念，設有閾值，擁塞窗口由1開始以指定速度增加，，遇到超時重傳則回到1，并且改變閾值。每次取接收方發來的窗口大小與擁塞窗口的較小的那個作為發送數據的大小，擁塞控制是TCP在傳輸時盡可能快的將數據傳輸，并且避免擁塞造成的一系列問題。是可靠性的保證，同時也是維護了傳輸的高效性。
擁塞控制具體動作：
參考文章>>
1.慢開始：
假設當前發送方擁塞窗口cwnd的值為1，而發送窗口swnd等于擁塞窗口cwnd，因此發送方當前只能發送一個數據報文段（擁塞窗口cwnd的值是幾，就能發送幾個數據報文段），接收方收到該數據報文段后，給發送方回復一個確認報文段，發送方收到該確認報文后，將擁塞窗口的值變為2。慢開始的窗口值以指數方式增長。當前的擁塞窗口cwnd的值已經等于慢開始門限值，之后改用擁塞避免算法。
2.擁塞避免：
也就是每個傳輸輪次，擁塞窗口cwnd只能線性加一，而不是像慢開始算法時，每個傳輸輪次，擁塞窗口cwnd按指數增長。當發生超時重傳時，回到慢開始算法，窗口值恢復為1。
3.快重傳：
快重傳是指使發送方盡快進行重傳，而不是等超時重傳計時器超時再重傳。
要求接收方不要等待自己需要發送數據時才進行捎帶確認，而是要立即發送確認；
即使收到了失序的報文段也要立即發出對已收到的報文段的重復確認，即通知發送方需要正確發送的報文序號；
發送方一旦收到3個連續的重復確認，就將相應的報文段立即重傳，而不是在規定時間內收不到對應確認信號，因為超時重傳計時器超時再重傳。
這樣：對于個別丟失的報文段，發送方不會出現超時重傳，也就不會誤認為出現了擁塞而采用擁塞避免算法，而是使用快恢復算法。
4.快恢復：
發送方一旦收到3個重復確認，就知道只是丟失了個別報文段，執行快恢復算法。
發送方將慢開始門限和擁塞窗口的值設為當前窗口值的一半，即快恢復算法。
15.TCP為什么會有多個CLOSE_WAIT狀態
參考文章>>
參考文章>>
客戶端發送FIN+seq釋放連接請求后，服務端發送ACK+ack+seq應答后進入CLOSE_WAIT狀態，如果大量存在CLOSE_WAIT狀態，說明服務端沒有發送FIN+seq+ACK+ack,可能正在忙于讀。
對于socket編程，有以下解決方案：
1.使用完socket調用close方法
2.read()讀取到的長度為0時，立即close
3.read返回-1，檢查error返回碼，如果不是AGAIN（現在沒數據稍后重新讀），則立即關閉
4.read設置超時，超時未讀到數據則關閉。
16.TCP有大量TIME_WAIT的原因
- 高并發讓服務器在短時間范圍內同時占用大量端口，而端口只0~65535的范圍，有限
- 短連接表示“業務處理+傳輸數據的時間 遠遠小于 TIMEWAIT超時的時間”的連接。
17.OSI七層協議及其作用
參考文章>>
參考文章>>
七層模型：
數據封裝：不同的協議層對數據包有不同的稱謂，在傳輸層叫做段（segment），在網絡層叫做數據報（datagram），在鏈路層叫做幀（frame）加上MAC頭，加完后再加上一個FCS校驗組成數據幀，就封裝完成了，然后在物理層通過Bit來傳輸。發到傳輸介質上，到達目的主機后每層協議再剝掉相應的首部，最后將應用層數據交給應用程序處理。
1.應用層：
直接向用戶提供服務，完成用戶希望在網絡上完成的各種工作。
2.表示層：
表示層（Presentation Layer）是OSI模型的第六層，它對來自應用層的命令和數據進行解釋，對各種語法賦予相應的含義，并按照一定的格式傳送給會話層。其主要功能是“處理用戶信息的表示問題，如編碼、數據格式轉換和加密解密”等。
3.會話層：
會話層的任務就是組織和協調兩個會話進程之間的通信，并對數據交換進行管理。
主要任務：
會話管理：允許用戶在兩個實體設備之間建立、維持和終止會話，并支持它們之間的數據交換。例如提供單方向會話或雙向同時會話，并管理會話中的發送順序，以及會話所占用時間的長短。
會話流量控制：提供會話流量控制和交叉會話功能。
尋址：使用遠程地址建立會話連接。
出錯控制：從邏輯上講會話層主要負責數據交換的建立、保持和終止，但實際的工作卻是接收來自傳輸層的數據，并負責糾正錯誤。會話控制和遠程過程調用均屬于這一層的功能。但應注意，此層檢查的錯誤不是通信介質的錯誤，而是磁盤空間、打印機缺紙等類型的高級錯誤。
4.傳輸層：
主要任務：
向用戶提供可靠的端到端的差錯和流量控制，保證報文的正確傳輸。
傳輸層的作用是向高層屏蔽下層數據通信的細節，即向用戶透明地傳送報文。該層常見的協議：TCP/IP中的TCP協議。
傳輸連接管理：提供建立、維護和拆除傳輸連接的功能。傳輸層在網絡層的基礎上為高層提供“面向連接”和“面向無接連”的兩種服務。
處理傳輸差錯：提供可靠的“面向連接”和不太可靠的“面向無連接”的數據傳輸服務、差錯控制和流量控制。在提供“面向連接”服務時，通過這一層傳輸的數據將由目標設備確認，如果在指定的時間內未收到確認信息，數據將被重發。
5.網絡層：
主要任務：
數據鏈路層的數據在這一層被轉換為數據包，然后通過路徑選擇、分段組合、順序、進/出路由等控制，將信息從一個網絡設備傳送到另一個網絡設備。
一般地，數據鏈路層是解決同一網絡內節點之間的通信，而網絡層主要解決不同子網間的通信。例如在廣域網之間通信時，必然會遇到路由（即兩節點間可能有多條路徑）選擇問題。
尋址：數據鏈路層中使用的物理地址（如MAC地址）僅解決網絡內部的尋址問題。在不同子網之間通信時，為了識別和找到網絡中的設備，每一子網中的設備都會被分配一個唯一的地址。由于各子網使用的物理技術可能不同，因此這個地址應當是邏輯地址（如IP地址），需要網絡層來找到指定IP地址。
路由算法：當源節點和目的節點之間存在多條路徑時，本層可以根據路由算法，通過網絡為數據分組選擇最佳路徑，并將信息從最合適的路徑由發送端傳送到接收端。
連接服務：與數據鏈路層流量控制不同的是，前者控制的是網絡相鄰節點間的流量，后者控制的是從源節點到目的節點間的流量。其目的在于防止阻塞，并進行差錯檢測。
6.數據鏈路層：
主要任務：
負責建立和管理節點間的鏈路。該層的主要功能是：通過各種控制協議，將有差錯的物理信道變為無差錯的、能可靠傳輸數據幀的數據鏈路。在物理層提供的比特流的基礎上，通過差錯控制、流量控制方法，使有差錯的物理線路變為無差錯的數據鏈路，即提供可靠的通過物理介質傳輸數據的方法。
該層通常又被分為介質訪問控制（MAC）和邏輯鏈路控制（LLC）兩個子層。
MAC子層的主要任務是解決共享型網絡中多用戶對信道競爭的問題，完成網絡介質的訪問控制；
LLC子層的主要任務是建立和維護網絡連接，執行差錯校驗、流量控制和鏈路控制。
具體工作：接收來自物理層的位流形式的數據，并封裝成幀，傳送到上一層；同樣，也將來自上層的數據幀，拆裝為位流形式的數據轉發到物理層；并且，還負責處理接收端發回的確認幀的信息，以便提供可靠的數據傳輸。
7.物理層：
主要功能：
利用傳輸介質為數據鏈路層提供物理連接，實現比特流的透明傳輸。
物理層的作用是實現相鄰計算機節點之間比特流的透明傳送，盡可能屏蔽掉具體傳輸介質和物理設備的差異。使其上面的數據鏈路層不必考慮網絡的具體傳輸介質是什么。“透明傳送比特流”表示經實際電路傳送后的比特流沒有發生變化，對傳送的比特流來說，這個電路好像是看不見的。
18.TCP/IP協議
參考文章>>
19.TCP/IP四層網絡模型
參考文章>>
TCP/IP協議族是一個四層協議系統，自底而上分別是數據鏈路層、網絡層、傳輸層和應用層。每一層完成不同的功能，且通過若干協議來實現，上層協議使用下層協議提供的服務。
1.應用層：
直接向用戶提供服務，完成用戶希望在網絡上完成的各種工作。
2.傳輸層：
傳輸層為兩臺主機上的應用程序提供端到端（end to end）的通信。傳輸層只關心通信的起始端和目的端，而不在乎數據包的中轉過程。
傳輸層協議：TCP協議、UDP協議。
TCP協議（Transmission Control Protocol，傳輸控制協議）為應用層提供可靠的、面向連接的和基于流（stream）的服務。TCP協議使用超時重傳、數據確認等方式來確保數據包被正確地發送至目的端，因此TCP服務是可靠的。使用TCP協議通信的雙方必須先建立TCP連接，并在內核中為該連接維持一些必要的數據結構，比如連接的狀態、讀寫緩沖區，以及諸多定時器等。當通信結束時，雙方必須關閉連接以釋放這些內核數據。TCP服務是基于流的。基于流的數據沒有邊界（長度）限制，它源源不斷地從通信的一端流入另一端。發送端可以逐個字節地向數據流中寫入數據，接收端也可以逐個字節地將它們讀出。
UDP協議（User Datagram Protocol，用戶數據報協議）則與TCP協議完全相反，它為應用層提供不可靠、無連接和基于數據報的服務。“不可靠”意味著UDP協議無法保證數據從發送端正確地傳送到目的端。如果數據在中途丟失，或者目的端通過數據校驗發現數據錯誤而將其丟棄，則UDP協議只是單地通知應用程序發送失敗。因此，使用UDP協議的應用程序通常要自己處理數據確認、超時重傳等邏輯。UDP協議是無連接的，即通信雙方不保持一個長久的聯系，因此應用程序每次發送數據都要明確指定接收端的地址（IP地址等信息）。基于數據報的服務，是相對基于流的服務而言的。每個UDP數據報都有一個長度，接收端必須以該長度為最小單位將其所有內容一次性讀出，否則數據將被截斷。
3.網絡層：
網絡層實現數據包的選路和轉發。主要負責從源地址到目的地址的最優路徑選擇。
網絡層最核心的協議是IP協議（Internet Protocol，因特網協議）。IP協議根據數據包的目的IP地址來決定如何投遞它。如果數據包不能直接發送給目標主機，那么IP協議就為它尋找一個合適的下一跳（next hop）路由器，并將數據包交付給該路由器來轉發。多次重復這一過程，數據包最終到達目標主機，或者由于發送失敗而被丟棄。可見，IP協議使用逐跳（hop by hop）的方式確定通信路徑。
WAN（Wide Area Network，廣域網）通常使用眾多分級的路由器來連接分散的主機或LAN（Local Area Network，局域網），因此，通信的兩臺主機一般不是直接相連的，而是通過多個中間節點（路由器）連接的。網絡層的任務就是選擇這些中間節點，以確定兩臺主機之間的通信路徑。同時，網絡層對上層協議隱藏了網絡拓撲連接的細節，使得在傳輸層和網絡應用程序看來，通信的雙方是直接相連的。
ICMP（Internet Control Message Protocol）Internet控制報文協議。它是TCP/IP協議簇的一個子協議，用于在IP主機、路由器之間傳遞控制消息。控制消息是指網絡通不通、主機是否可達、路由是否可用等網絡本身的消息。這些控制消息雖然并不傳輸用戶數據，但是對于用戶數據的傳遞起著重要的作用
4.數據鏈路層：
數據鏈路層實現了網卡接口的網絡驅動程序，以處理數據在物理媒介（比如以太網、令牌環等）上的傳輸。
數據鏈路層兩個常用的協議是ARP協議（Address Resolve Protocol，地址解析協議）和RARP協議（ReverseAddress Resolve Protocol，逆地址解析協議）。它們實現了IP地址和機器物理地址（通常是MAC地址，以太網、令牌環和802.11無線網絡都使用MAC地址）之間的相互轉換。即通過IP地址找到路由器。
ARP協議：網絡層使用IP地址尋址一臺機器，而數據鏈路層使用物理地址尋址一臺機器，因此網絡層必須先將目標機器的IP地址轉化成其物理地址，才能使用數據鏈路層提供的服務。
RARP協議：僅用于網絡上的某些無盤工作站。因為缺乏存儲設備，無盤工作站無法記住自己的IP地址，但它們可以利用網卡上的物理地址來向網絡管理者（服務器或網絡管理軟件）查詢自身的IP地址。運行RARP服務的網絡管理者通常存有該網絡上所有機器的物理地址到IP地址的映射。
21.TCP的沾包問題
參考文章1>>
參考文章2>>
粘包的原因：
- 產生TCP粘包和拆包問題的主要原因是，操作系統在發送TCP數據的時候，底層會有一個緩沖區，例如1024個字節大小，如果一次請求發送的數據量比較小，沒達到緩沖區大小，TCP則會將多個請求合并為同一個請求進行發送，這就形成了粘包問題；
拆包原因：
- 如果一次請求發送的數據量比較大，超過了緩沖區大小，TCP就會將其拆分為多次發送，這就是拆包，也就是將一個大的包拆分為多個小包進行發送。
粘包和拆包的三種情況：
- A和B兩個包都剛好滿足TCP緩沖區的大小，或者說其等待時間已經達到TCP等待時長，從而還是使用兩個獨立的包進行發送；
- A和B兩次請求間隔時間內較短，并且數據包較小，因而合并為同一個包發送給服務端；
- B包比較大，因而將其拆分為兩個包B_1和B_2進行發送，而這里由于拆分后的B_2比較小，其又與A包合并在一起發送。
解決方案：
- 使用帶消息頭的協議、消息頭存儲消息開始標識及消息長度信息，服務端獲取消息頭的時候解析出消息長度，然后向后讀取該長度的內容。
- 設置定長消息，服務端每次讀取既定長度的內容作為一條完整消息。
- 設置消息邊界，服務端從網絡流中按消息編輯分離出消息內容
22.MTU
參考文章>>
MTU:最大傳輸單元，由不同的數據鏈路層對應物理層產生的（硬件規定），以太網的MTU＝1500字節，即數據鏈路層發送的幀中的數據大小不能超過1500，最小46。太大會一直占用傳輸線路，別的數據需要等待，太小會影響效率，需要一直切片，且需要包裝各種頭，導致實際發送數據并不多。
MSS：最大分節大小，為TCP數據包每次傳輸的最大數據分段大小,MSS的取值受限于MTU。
23.socket編寫TCP協議的流程
參考文章>>
1.服務端創建socket，綁定IP地址和端口號（bind），之后注冊監聽（listen）。
2.客戶端創建socket，對指定IP和端口號發送鏈接請求（connect）。
3.服務端socket接收到客戶端socket發來的連接請求，被動打開，調用accept函數接收請求，建立連接
4.建立連接之后可以write（recv）和send
5.close關閉socket。
參考文章>>
24.ARP協議原理
參考文章>>
1、ARP，意思是地址解析協議。每一臺主機在出廠的時候都會有一個唯一標識自己的物理地址，也就是MAC地址。每一臺主機在本地的ARP 報文緩沖區里都會維護一張ARP 列表，里面存放的是IP 地址與MAC 地址的映射關系。
2、當源主機向目標主機發送數據包時，在數據鏈路層傳輸時需要知道目標主機的MAC 地址。因此，源主機 會首先在本地的ARP 列表中查詢該目標主機IP 地址所對應的MAC 地址。如果存在，則說明查詢成功，于是源主機便向這個MAC 地址發送數據包即可。
如果不存在，源主機會在本地網段內發起一個ARP 請求的廣播包，用來查詢目標主機IP 地址對應的MAC 地址。
該ARP 請求包里面包含了“源主機IP 地址、源主機MAC 地址、目標主機IP 地址”。
3、于是，在本地網段內的所有主機都會收到這個ARP 請求包。當主機收到這個ARP 請求包后，會首先提取出ARP 請求包里面的目標主機IP地址，查看這個IP 是否與自己的IP 一致，如果不一致，則丟棄這個請求包，不予理會。如果一致，則該主機便會將這個請求包里的源主機IP 地址和源主機MAC 地址一 一添加到本地的ARP 列表中（如果已經存在了，便會覆蓋它）。然后，這臺主機便會返回一個包含了本機MAC 地址的ARP 響應數據包給源主機，告訴它自己的MAC 地址。
4、源主機收到這個ARP 響應數據包后，將目標主機的IP 地址和MAC 地址一 一添加到自己的ARP 列表中。然后，便根據此信息進行數據的傳輸。如果源主機一直得不到ARP 響應數據包，則說明ARP 查詢失敗。
25.DNS解析過程
參考文章>>
參考文章>>
DNS解析過程：
- 主機向本地域名服務器的查詢一般都是采用遞歸查詢：
所謂遞歸查詢就是：如果主機所詢問的本地域名服務器不知道被查詢的域名的IP地址，那么本地域名服務器就以DNS客戶的身份，向其它根域名服務器繼續發出查詢請求報文(即替主機繼續查詢)，而不是讓主機自己進行下一步查詢。因此，遞歸查詢返回的查詢結果或者是所要查詢的IP地址，或者是報錯，表示無法查詢到所需的IP地址。
- 本地域名服務器向根域名服務器的查詢的迭代查詢：
迭代查詢的特點：當根域名服務器收到本地域名服務器發出的迭代查詢請求報文時，要么給出所要查詢的IP地址，要么告訴本地服務器：“你下一步應當向哪一個域名服務器進行查詢”。然后讓本地服務器進行后續的查詢。
根域名服務器通常是把自己知道的頂級域名服務器的IP地址告訴本地域名服務器，讓本地域名服務器再向頂級域名服務器查詢。頂級域名服務器在收到本地域名服務器的查詢請求后，要么給出所要查詢的IP地址，要么告訴本地服務器下一步應當向哪一個權限域名服務器進行查詢。最后，知道了所要解析的IP地址或報錯，然后把這個結果返回給發起查詢的主機。
DNS采用什么協議：
DNS在區域傳輸的時候使用TCP協議，其他時候使用UDP協議。
DNS區域傳輸的時候使用TCP協議：
原因1.輔域名服務器會定時（一般3小時）向主域名服務器進行查詢以便了解數據是否有變動。如有變動，會執行一次區域傳送，進行數據同步。區域傳送使用TCP而不是UDP，因為數據同步傳送的數據量比一個請求應答的數據量要多得多。
原因2.TCP是一種可靠連接，保證了數據的準確性。
域名解析時使用UDP協議：
客戶端向DNS服務器查詢域名，一般返回的內容都不超過512字節，用UDP傳輸即可。不用經過三次握手，這樣DNS服務器負載更低，響應更快。理論上說，客戶端也可以指定向DNS服務器查詢時用TCP，但事實上，很多DNS服務器進行配置的時候，僅支持UDP查詢包。
26.1 TCP與UDP的優缺點
TCP的優點： 可靠，穩定 TCP的可靠體現在TCP在傳遞數據之前，會有三次握手來建立連接，而且在數據傳遞時，有確認、窗口、重傳、擁塞控制機制，在數據傳完后，還會斷開連接用來節約系統資源。 TCP的缺點： 慢，效率低，占用系統資源高，易被攻擊 TCP在傳遞數據之前，要先建連接，這會消耗時間，而且在數據傳遞時，確認機制、重傳機制、擁塞控制機制等都會消耗大量的時間，而且要在每臺設備上維護所有的傳輸連接，事實上，每個連接都會占用系統的CPU、內存等硬件資源。 而且，因為TCP有確認機制、三次握手機制，這些也導致TCP容易被人利用，實現DOS、DDOS、CC等攻擊。
UDP的優點： 快，比TCP稍安全 UDP沒有TCP的握手、確認、窗口、重傳、擁塞控制等機制，UDP是一個無狀態的傳輸協議，所以它在傳遞數據時非常快。沒有TCP的這些機制，UDP較TCP被攻擊者利用的漏洞就要少一些。但UDP也是無法避免攻擊的，比如：UDP Flood攻擊…… UDP的缺點： 不可靠，不穩定 因為UDP沒有TCP那些可靠的機制，在數據傳遞時，如果網絡質量不好，就會很容易丟包。 基于上面的優缺點，那么： 什么時候應該使用TCP： 當對網絡通訊質量有要求的時候，比如：整個數據要準確無誤的傳遞給對方，這往往用于一些要求可靠的應用，比如HTTP、HTTPS、FTP等傳輸文件的協議，POP、SMTP等郵件傳輸的協議。 在日常生活中，常見使用TCP協議的應用如下： 瀏覽器，用的HTTP FlashFXP，用的FTP Outlook，用的POP、SMTP Putty，用的Telnet、SSH QQ文件傳輸 ………… 什么時候應該使用UDP： 當對網絡通訊質量要求不高的時候，要求網絡通訊速度能盡量的快，這時就可以使用UDP。 比如，日常生活中，常見使用UDP協議的應用如下： QQ語音 QQ視頻 TFTP ……
有些應用場景對可靠性要求不高會用到UPD，比如長視頻，要求速率
小結TCP與UDP的區別：
1.基于連接與無連接；
2.對系統資源的要求（TCP較多，UDP少）；
3.UDP程序結構較簡單；
4.流模式與數據報模式 ；
5.TCP保證數據正確性，UDP可能丟包，TCP保證數據順序，UDP不保證。
tcp協議和udp協議的差別
TCP UDP
是否連接 面向連接 面向非連接
傳輸可靠性 可靠 不可靠
應用場合 傳輸大量數據 少量數據
速度 慢 快
TCP與UDP區別總結：
1、TCP面向連接（如打電話要先撥號建立連接）;UDP是無連接的，即發送數據之前不需要建立連接
2、TCP提供可靠的服務。也就是說，通過TCP連接傳送的數據，無差錯，不丟失，不重復，且按序到達;UDP盡最大努力交付，即不保證可靠交付
3、TCP面向字節流，實際上是TCP把數據看成一連串無結構的字節流;UDP是面向報文的
UDP沒有擁塞控制，因此網絡出現擁塞不會使源主機的發送速率降低（對實時應用很有用，如IP電話，實時視頻會議等）
4、每一條TCP連接只能是點到點的;UDP支持一對一，一對多，多對一和多對多的交互通信
5、TCP首部開銷20字節;UDP的首部開銷小，只有8個字節
6、TCP的邏輯通信信道是全雙工的可靠信道，UDP則是不可靠信道
26.TCP/UDP的區別
TCP面向對象的含義：============>
連接建立：TCP需要三次握手，UDP不需要任何準備就可以傳輸數據。因此UDP更快速。
連接狀態：TCP需要維護連接狀態，包括發送接收緩存，擁塞控制參數以及序號與確認號參數，UDP不維護連接狀態，也不追蹤這些參數。
參考文章>>
TCP與UDP的區別主要表現在以下幾個方面：
1）TCP是面向連接的傳輸控制協議，而UDP提供的是無連接的數據報服務；
2）TCP是一種流模式的協議，UDP是一種數據報模式的協議；
3）TCP具有高可靠性，確保傳輸數據的正確性，不出現丟失或亂序；UDP在傳輸數據前不建立連接，不對數據報進行檢查和修改，無需等待對方的應答，所以會出現分組丟失、重復、亂序，應用程序需要負責傳輸可靠性方面的所有工作；
4）TCP對系統資源要求較多，UDP要求較少；
5）UDP具有較好的實時性，工作效率比TCP高；
6）UDP的包頭結構比TCP的包頭結構簡單，因此網絡開銷也小；
7）TCP提供流量/擁塞控制，而UDP不提供。
UDP：
1）UDP無連接，時間上不存在建立連接需要的時延。DNS基于UDP
2）TCP首部20字節，UDP首部8字節。
3）UDP沒有擁塞控制和流量控制
4）UDP是面向報文的，對應用層交下來的報文，添加首部后直接鄉下交付為IP層，既不合并，也不拆分，保留這些報文的邊界。對IP層交上來UDP用戶數據報，在去除首部后就原封不動地交付給上層應用進程，報文不可分割，是UDP數據報處理的最小單位。
5）UDP常用一次性傳輸比較少量數據的網絡應用，如DNS,SNMP等。
UDP特點：
- 每個分組都攜帶完整的目的地址；
- 發送數據之前不需要建立鏈接；
- 不對數據包的順序進行檢查，不能保證分組的先后順序；
- 不進行分組出錯的恢復和重傳；
- 不保證數據傳輸的可靠性。
26.UDP如何保證可靠傳輸
參考文章>>
1、UDP報文丟失問題：
??因為UDP自身的特點，決定了UDP會相對于TCP存在一些難以解決的問題。第一個就是UDP報文缺失問題。在UDP服務器客戶端的例子中，如果客戶端發送的數據丟失，服務器會一直等待，直到客戶端的合法數據過來。如果服務器的響應在中間被路由丟棄，則客戶端會一直阻塞，直到服務器數據過來。
【問題解決方法】：
使用信號SIGALRM為recvfrom設置超時。首先我們為SIGALARM建立一個信號處理函數，并在每次調用前通過alarm設置一個5秒的超時。如果recvfrom被我們的信號處理函數中斷了，那就超時重發信息；若正常讀到數據了，就關閉報警時鐘并繼續進行下去；
使用select為recvfrom設置超時。
2、UDP報文亂序問題：
所謂亂序就是發送數據的順序和接收數據的順序不一致，例如發送數據的順序為A、B、C，但是接收到的數據順序卻為：A、C、B。產生這個問題的原因在于，每個數據報走的路由并不一樣，有的路由順暢，有的卻擁塞，這導致每個數據報到達目的地的順序就不一樣了。UDP協議并不保證數據報的按序接收。
【問題解決方法】：發送端在發送數據時加入數據報序號，這樣接收端接收到報文后可以先檢查數據報的序號，并將它們按序排隊，形成有序的數據報。
3、UDP流量控制問題：
??總所周知，TCP有滑動窗口進行流量控制和擁塞控制，反觀UDP因為其特點無法做到。UDP接收數據時直接將數據放進緩沖區內，如果用戶沒有及時將緩沖區的內容復制出來放好的話，后面的到來的數據會接著往緩沖區放，當緩沖區滿時，后來的到的數據就會覆蓋先來的數據而造成數據丟失（因為內核使用的UDP緩沖區是環形緩沖區）。因此，一旦發送方在某個時間點爆發性發送消息，接收方將因為來不及接收而發生信息丟失。
【問題解決方法】：解決方法一般采用增大UDP緩沖區，使得接收方的接收能力大于發送方的發送能力。
UDP如何保證可靠傳輸：
??由于在傳輸層UDP已經是不可靠的連接，那就要在應用層自己實現一些保障可靠傳輸的機制。簡單來講，要使用UDP來構建可靠的面向連接的數據傳輸，就要實現類似于TCP協議的：
超時重傳（定時器）【解決報文丟失問題】；
有序接受 （添加包序號）【解決包亂序問題】；
應答確認 （Seq/Ack應答機制）【保證可靠性】；
滑動窗口流量控制等機制 （滑動窗口協議）【解決流量控制問題】。
UDP改進網絡—UDT
目前已經有一些實現UDP可靠傳輸的機制，比如UDT（UDP-based Data Transfer Protocol）：基于UDP的數據傳輸協議（UDP-based Data Transfer Protocol，簡稱UDT）是一種互聯網數據傳輸協議。UDT的主要目的是支持高速廣域網上的海量數據傳輸，而互聯網上的標準數據傳輸協議TCP在高帶寬長距離網絡上性能很差。 顧名思義，UDT建于UDP之上，并引入新的擁塞控制和數據可靠性控制機制。UDT是面向連接的雙向的應用層協議。它同時支持可靠的數據流傳輸和部分可靠的數據報傳輸。 由于UDT完全在UDP上實現，它也可以應用在除了高速數據傳輸之外的其它應用領域，例如點到點技術（P2P），防火墻穿透，多媒體數據傳輸等等。
27.TCP協議：reset
RST標志位
RST表示復位，用來異常的關閉連接，在TCP的設計中它是不可或缺的。就像上面說的一樣，發送RST包關閉連接時，不必等緩沖區的包都發出去（不像上面的FIN包），直接就丟棄緩存區的包發送RST包。而接收端收到RST包后，也不必發送ACK包來確認。
幾種情形：
- 1，客戶端嘗試與服務器未對外提供服務的端口建立TCP連接，服務器將會直接向客戶端發送reset報文。
- 2，客戶端和服務器的某一方在交互的過程中發生異常（如程序崩潰等），該方系統將向對端發送TCP reset報文，告之對方釋放相關的TCP連接。
- 3，接收端收到TCP報文，但是發現該TCP的報文，并不在其已建立的TCP連接列表內，則其直接向對端發送reset報文。
- 4，在交互的雙方中的某一方長期未收到來自對方的確認報文，則其在超出一定的重傳次數或時間后，會主動向對端發送reset報文釋放該TCP連接。
- 5，有些應用開發者在設計應用系統時，會利用reset報文快速釋放已經完成數據交互的TCP連接，以提高業務交互的效率。
參考文章>>
參考文章>>
28.如何通過局域網獲得另一臺電腦的一個文件
參考文章>>
29.ARQ協議
參考文章>>
自動重傳請求（Automatic Repeat-reQuest，ARQ）是OSI模型中數據鏈路層的錯誤糾正協議之一。
ARQ包括：停止等待ARQ協議、回退ARQ和連續ARQ協議，錯誤檢測（Error Detection）、正面確認（Positive Acknowledgment）、超時重傳（Retransmission after Timeout）和 負面確認及重傳（Negative Acknowledgment and Retransmission）等機制。
傳統自動重傳請求分成為三種：停等式(stop-and-wait）ARQ，回退n幀（go-back-n）ARQ，以及選擇性重傳（selective repeat）ARQ。后兩種協議是滑動窗口技術與請求重發技術的結合，由于窗口尺寸開到足夠大時，幀在線路上可以連續地流動，因此又稱其為連續ARQ協議。三者的區別在于對于出錯的數據報文的處理機制不同。三種ARQ協議中，復雜性遞增，效率也遞增。除了傳統的ARQ，還有混合ARQ（Hybrid-ARQ）。
非連續ARQ協議：
1.停等式：
停止并等待協議的工作原理如下：
- 發送點對接收點發送數據包，然后等待接收點回復ACK并且開始計時。
- 在等待過程中，發送點停止發送新的數據包。
- 當數據包沒有成功被接收點接收時，接收點不會發送ACK. 這樣發送點在等待指定時間后，重新發送數據包。
- 反復以上步驟直到收到從接收點發送的ACK.
連續ARQ協議：
1.回退N幀協議:
在回退n幀的ARQ中，當發送方接收到接收方的狀態報告指示報文出錯后，發送方將重傳過去的n個報文。回退N，發送窗口大于1，接收窗口等于1。允許發送方可以連續發送信息幀，但是，一旦某幀發生錯誤，必須重新發送該幀及其后的n幀。這種方式提高了信道的利用率，但允許已發送有待于確認的幀越多，可能要退回來重發的幀也越多。
3.選擇重傳協議（Selective Repeat):
發送點連續發送數據包但對每個數據包都設有個一個計時器。
當在一定時間內沒有收到某個數據包的ACK時，發送點只重新發送那個沒有ACK的數據包，這個方法的缺點是接收點收到的數據包的順序可能不是發送的數據包順序。因此在數據包里必須含有順序字符來幫助接受點來排序。
- 接收點丟棄從第一個沒有收到的數據包開始的所有數據包。
- 發送點收到NACK后，從NACK中指明的數據包開始重新發送
30.TCP的滑動窗口
滑動窗口的三個動作：
- 窗口左邊沿向右邊沿靠近為窗口合攏。這種現象發生在數據被發送和確認時。
- 當窗口右邊沿向右移動時將允許發送更多的數據，我們稱之為窗口張開。這種現象發生在另一端的接收進程讀取已經確認的數據并釋放了T C P的接收緩存時。
- 當右邊緣向左移動時，稱之為窗口收縮。
窗口有3種動作：展開（右邊向右），合攏（左邊向右），收縮（右邊向左）這三種動作受接收端的控制。
合攏：表示已經收到相應字節的確認了
展開：表示允許緩存發送更多的字節
收縮（非常不希望出現的，某些實現是禁止的）：表示本來可以發送的，現在不能發送；但是如果收縮的是那些已經發出的，就會有問題；為了避免，收端會等待到緩存中有更多緩存空間時才進行通信。
TCP通過滑動窗口進行流量控制：
1、流量控制是管理兩端的流量，以免會產生發送過快導致收端溢出，或者因收端處理太快而浪費時間的狀態。用的是：滑動窗口，以字節為單位。
2.發端窗口的大小取決于收端的窗口大小rwnd（TCP報文的窗口大小字段）和擁塞窗口大小cwnd（見擁塞控制），發端窗口大小 = min{ rwnd , cwnd };
31. TCP的保活機制
為什么需要保活機制：
1.怎么判斷對方是否還在線。這是因為，TCP對于非正常斷開的連接系統并不能偵測到（比如網線斷掉）。
2.長時間沒有任何數據發送，連接可能會被中斷。這是因為，網絡連接中間可能會經過路由器、防火墻等設備，而這些有可能會對長時間沒有活動的連接斷掉。
保活機制的實現：
保活機制是由一個保活計時器實現的。當計時器被激發，連接一段將發送一個保活探測報文，另一端接收報文的同時會發送一個ACK作為響應。
保活時間：默認7200秒（2小時）
保活時間間隔：默認75秒
保活探測數：默認9次
客戶端一般處于下面四種狀態：
客戶主機依然正常運行，并從服務器可達。客戶的TCP響應正常，而服務器也知道對方是正常的，服務器在兩小時后將保活定時器復位。
客戶主機已經崩潰，并且關閉或者正在重新啟動。在任何一種情況下，客戶的TCP都沒有響應。服務端將不能收到對探測的響應，并在75秒后超時。服務器總共發送10個這樣的探測 ，每個間隔75秒。如果服務器沒有收到一個響應，它就認為客戶主機已經關閉并終止連接。
客戶主機崩潰并已經重新啟動。服務器將收到一個對其保活探測的響應，這個響應是一個復位，使得服務器終止這個連接。
客戶機正常運行，但是服務器不可達，這種情況與2類似，TCP能發現的就是沒有收到探查的響應。
保活機制的弊端：
在出現短暫的網絡錯誤的時候，保活機制會使一個好的連接斷開；
保活機制會占用不必要的帶寬；
解決方案：保活功能在默認情況下是關閉的。沒有經過應用層的請求，Linux系統不會提供保活功能。
32.socket編程中TCP三次握手
1.基于TCP的socket
- 客戶端connect函數發起三次握手
- 服務端listen接受三次握手
三次握手后服務器端和客戶端成功建立起連接(準確講是成功交換了彼此說話的起始序號)，服務器和相應客戶端的連接信息會被放到操作系統的等待隊列中，因為一個服務器可以和多個客戶端建立連接，三次握手成功后需要維護這些客戶端的連接信息，因此這些信息通常是操作系統用隊列來維護的。
accept函數的作用：，服務器端調用accept函數后會從隊列中取出一個已經成功三次握手的連接數據，此后雙方就可以進行正常通信了。
accept函數不會影響三次握手，但該函數能否很快返回是和三次握手有關的。只有當三次握手完成后發生了通信的連接，才會被accept取出。
33.UDP如何實現一對多
基于UDP(面向對象)的socket編程的服務器端程序如下：
1、創建套接字（socket）
2、將套接字綁定到一個本地地址和端口上（bind）
3、等待接收數據（recvfrom）
4、關閉套接字
基于UDP(面向對象)的socket編程的客戶端程序如下：
1、創建套接字（socket）
2、填充服務器地址
3、向服務器發送數據（sendto） 沒有connect環節，無連接狀態，知道服務器IP+端口號就能發送。
4、關閉套接字
基于UDP的socket編程：
服務端：
建套接字(socket)–>填充本地信息(sockaddr_in)–>把socket與IP地址加端口號綁定在一起（bind）–>接收(recvfrom)和回發(sendto)。
客戶端：
創建套接字(socket)–>填充服務器的地址信息(sockaddr_in)–>發送(sendto)和接收回顯(recvfrom)
源代碼參考>>
34.TCP/IP模型各層的網絡攻擊
參考文章>>
35.TIME_WAIT過多
從服務器來講，短時間內關閉了大量的Client連接，就會造成服務器上出現大量TIME_WAIT連接，嚴重消耗著服務器的資源，此時部分客戶端就會顯示連接不上。
從客戶端來講，客戶端TIME_WAIT過多，就會導致端口資源被占用，因為端口就65536個，被占滿就會導致無法創建新的連接。
解決辦法：
- 服務器可以設置 SO_REUSEADDR 套接字選項來避免 TIME_WAIT狀態，此套接字選項告訴內核，即使此端口正忙（處于TIME_WAIT狀態），也請繼續并重用它。
- 調整系統內核參數，修改**/etc/sysctl.conf文件，即修改 net.ipv4.tcp_tw_reuse 和 tcp_timestamps。net.ipv4.tcp_tw_reuse = 1 表示開啟重用。允許將TIME-WAIT sockets**重新用于新的TCP連 接，默認為0，表示關閉； net.ipv4.tcp_tw_recycle = 1 表示開啟TCP連接中TIME-WAIT sockets的快速回收，默認為 0，表示關閉。
- 強制關閉，發送 RST 包越過TIME_WAIT狀態，直接進入CLOSED狀態
36.TIME_WAIT過多如何排查
1.首先 使用命令netstat -n | awk ，查看當前各種狀態的數量
netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}' TIME_WAIT 15586 CLOSE_WAIT 343 ESTABLISHED 5812.使用 netstat -anp |grep TIME_WAIT | head定位TIME_WAIT的
netstat -anp |grep TIME_WAIT | head tcp 0 0 127.0.0.1:37545 127.0.0.1:50000 TIME_WAIT - tcp 0 0 127.0.0.1:40285 127.0.0.1:50000 TIME_WAIT - tcp 0 0 127.0.0.1:57127 127.0.0.1:50000 TIME_WAIT - tcp 0 0 127.0.0.1:34796 127.0.0.1:50000 TIME_WAIT -37.CLOSE_WAIT產生的原因及解決
被動關閉的一方未發FIN導致其一直處于CLOSE_WAIT。
原因：
- 被動關閉的一方還用數據沒有發完，導致FIN沒發。
- 被動關閉的一方阻塞在IO處。
- 服務端沒有調用TCP的close(socket)。
解決：
一是對服務端代碼進行改善，查看服務端代碼在處理完畢客戶端請求，并在客戶端數據處理完畢后，有沒有進行使用close(socket)操作.
二是使用keepalive保活機制來對這種半關閉連接進行檢測
int keepAlive = 1;//開啟keepalive屬性
int keepIdle = 60;//如果60秒內沒有任何數據往來，則進行探測
int keepInterval = 6;//探測時發包的時間間隔為6秒
int keepCount = 3;//探測嘗試的次數，如果第一次探測包就收到相應，以后的2次就不再發
//keepalive
setsockopt(m_iSock,SOL_SOCKET, SO_KEEPALIVE, (void*)&keepAlive, sizeof(int));
setsockopt(m_iSock,SOL_TCP,TCP_KEEPIDLE,(void*)&keepIdle, sizeof(int));
setsockopt(m_iSock,SOL_TCP, TCP_KEEPINTVL,(void*)&keepInterval,sizeof(int));
setsockopt(m_iSock,SOL_TCP, TCP_KEEPCNT,(void*)&keepCount,sizeof(int));
38.數據包從一個主機發送到另一個主機
參考文章>>
39.IPV6和IPV4
IPV6 共2的128次方個IP地址
IPV4 共2的32次方個IP地址
IPV6的優點：
- 1.ipv6的地址數量是2的128次方個，完全夠用
- 2.IPv6具有更高的安全性通過IPv6協議的安全機制，可對網絡層的數據進行加密，對IP報文進行校驗，這提高了數據的安全性。
- 3.IPV6傳輸速度更快IPv6的地址分配一開始就遵循聚類的原則，這大大減小了路由器中路由表的長度，提高了路由器轉發數據包的速度。
- 4.IPv6還擁有更好的頭部格式，IPV6使用新的頭部格式，其選項與基本頭部分開，這簡化和加速了路由選擇過程，提高了效率。
40.TCP超時重傳的次數限制
參考文章>>
HTTP
1.HTTP/HTTPS
HTTP/HTTPS對比>>
HTTP是明文傳輸的，傳輸過程中容易被攔截、修改或者偽造請求；HTTPS則是在HTTP基礎上進行進行了一些信息保護，相比HTTP來說更為安全。
HTTP的缺點：
使用明文通信，一些重要的內容會被竊聽（密碼）。
不能驗證對方的身份，可能是偽造的信息。
無法驗證報文的完整性，有可能已經被修改。
HTTPS如何解決HTTP的問題：
HTTPS 只是在 HTTP 的基礎之上增加了加密處理、認證機制和完整性保護，即 HTTPS = HTTP + 加密 + 認證 + 完整性保護。
加密:HTTPS 通過對數據加密來使其免受竊聽者對數據的監聽，這就意味著當用戶在瀏覽網站時，沒有人能夠監聽他和網站之間的信息交換，或者跟蹤用戶的活動，訪問記錄等，從而竊取用戶信息。
數據一致性:數據在傳輸的過程中不會被竊聽者所修改，用戶發送的數據會完整的傳輸到服務端，保證用戶發的是什么，服務器接收的就是什么。
身份認證:是指確認對方的真實身份，也就是證明你是你（可以比作人臉識別），它可以防止中間人攻擊并建立用戶信任。
1.HTTP詳解
詳解文章>>
請求報文的格式
響應報文的格式
2.對稱加密和非對稱加密
參考文章>>
非對稱加密指的是：加密和解密使用不同的秘鑰，一把作為公開的公鑰，另一把作為私鑰。公鑰加密的信息，只有私鑰才能解密。私鑰加密的信息，只有公鑰才能解密。常見的非對稱加密算法：RSA，ECC。
對稱加密：指的就是加密和解密使用同一個秘鑰，所以叫做對稱加密。對稱加密只有一個秘鑰，作為私鑰。常見的對稱加密算法：DES，AES，3DES等等。
對稱加密算法相比非對稱加密算法來說，加解密的效率要高得多。但是缺陷在于對于秘鑰的管理上，以及在非安全信道中通訊時，密鑰交換的安全性不能保障。所以在實際的網絡環境中，會將兩者混合使用.
3.HTTPS的握手方式
SSL協議：SSL是“Secure Sockets Layer”的縮寫，中文叫做“安全套接層”，其出現就是為了解決HTTP傳輸不安全的問題。
SSL協議的作用：
- 認證用戶和服務器，確保數據發送到正確的客戶端和服務器；
- 加密數據以防止數據中途被竊取；
- 維護數據的完整性，確保數據在傳輸過程中不被改變。
流程：
-
1.客戶端給服務端發送一個報文，報文中包括：客戶端能支持的TLS的最高版本，一個隨機數A，客戶端所能支持的加密算法集合以及壓縮算法集合。
-
2.服務端收到客戶端的報文后，根據報文中的TLS（SSL）版本，確定一個TLS版本，自己生成個隨機數B，從客戶端傳過來的加密算法集合中挑一個具體的加密算法M（包括：非對稱加密算法用于加密上圖的pre-mastersecret，比如RSA算法、對稱加密算法用于數據傳輸時雙方使用的加密自己的內容解密對方內容的依據、MAC算法用于校驗信息是否被篡改、偽隨機算法用于生成最終通訊時對稱加密算法所需要的密鑰mastersecret），從壓縮算法集合中挑一個具體的壓縮算法N。然后發送一個響應包給客戶端，這個報文就包含剛才提到的：TLS的版本，隨機數B，加密算法M，壓縮算法N。
-
3.第一步和第二步協商好了握手過程中需要的算法。
-
4.網站的管理員需要向CA機構進行申請，將自己的公鑰提交給CA機構。CA機構則會使用我們提交的公鑰，再加上一系列其他的信息，如網站域名****、有效時長等，來制作證書。
-
5.證書制作完成后，CA機構會使用自己的私鑰對其加密，并將加密后的數據返回給我們，我們只需要將獲得的加密數據配置到網站服務器上即可。
-
6.然后，每當有瀏覽器請求我們的網站時，首先會將這段加密數據返回給瀏覽器，此時瀏覽器會用CA機構的公鑰來對這段數據解密。
-
7.如果能解密成功，就可以得到CA機構給我們網站頒發的證書了，其中當然也包括了我們網站的公鑰。
參考文章>>
4.XSS攻擊：
XSS攻擊通常指的是通過利用網頁開發時留下的漏洞，通過巧妙的方法注入惡意指令代碼到網頁，使用戶加載并執行攻擊者惡意制造的網頁程序。
最常見的幾種分類：反射型（非持久型）XSS、存儲型（持久型）XSS、DOM型XSS、通用型XSS、突變型XSS。
參考文章>>
5.GET方法與POST方法的區別
1.GET提交的數據會放在URL之后，也就是請求行里面，以?分割URL和傳輸數據，參數之間以&相連，如EditBook?name=test1&id=123456.（請求頭里面那個content-type做的這種參數形式） POST方法是把提交的數據放在HTTP包的請求體中。
2.GET提交的數據大小有限制（因為瀏覽器對URL的長度有限制），而POST方法提交的數據沒有限制.
3.GET方法用于信息獲取，它是安全的（安全：指非修改信息，如數據庫方面的信息），而POST方法是用于修改服務器上資源的請求；
4.GET請求的數據會附在URL之后，而POST方法提交的數據則放置在HTTP報文實體的主體里，所以POST方法的安全性比GET方法要高；
5.GET方法傳輸的數據量一般限制在2KB，其原因在于：GET是通過URL提交數據，而URL本身對于數據沒有限制，但是不同的瀏覽器對于URL是有限制的，比如IE瀏覽器對于URL的限制為2KB，而Chrome，FireFox瀏覽器理論上對于URL是沒有限制的，它真正的限制取決于操作系統本身；POST方法對于數據大小是無限制的，真正影響到數據大小的是服務器處理程序的能力。
使用上的區別：
GET使用URL或Cookie傳參，而POST將數據放在BODY中”，這個是因為HTTP協議用法的約定。
GET方式提交的數據有長度限制，則POST的數據則可以非常大”，這個是因為它們使用的操作系統
和瀏覽器設置的不同引起的區別。
POST比GET安全，因為數據在地址欄上不可見”，這個說法沒毛病，但依然不是GET和POST本身的區別。
本質區別：
GET和POST最大的區別主要是GET請求是冪等性的，POST請求不是。這個是它們本質區別。
冪等性是指一次和多次請求某一個資源應該具有同樣的副作用。簡單來說意味著對同一URL的多個請求應該返回同樣的結果。
9.云計算
云計算（cloud computing）是分布式計算的一種，指的是通過網絡“云”將巨大的數據計算處理程序分解成無數個小程序，然后，通過多部服務器組成的系統進行處理和分析這些小程序得到結果并返回給用戶。云計算早期，簡單地說，就是簡單的分布式計算，解決任務分發，并進行計算結果的合并。因而，云計算又稱為網格計算。通過這項技術，可以在很短的時間內（幾秒鐘）完成對數以萬計的數據的處理，從而達到強大的網絡服務。
現階段所說的云服務已經不單單是一種分布式計算，而是分布式計算、效用計算、負載均衡、并行計算、網絡存儲、熱備份冗雜和虛擬化等計算機技術混合演進并躍升的結果。
10.https如何保證公鑰可信性
參考文章>>
CA機構專門用于給各個網站簽發數字證書，從而保證瀏覽器可以安全地獲得各個網站的公鑰。
-
網站的管理員需要向CA機構進行申請，將自己的公鑰提交給CA機構。CA機構則會使用我們提交的公鑰，再加上一系列其他的信息，如網站域名****、有效時長等，來制作證書。
-
證書制作完成后，CA機構會使用自己的私鑰對其加密，并將加密后的數據返回給我們，我們只需要將獲得的加密數據配置到網站服務器上即可。
-
然后，每當有瀏覽器請求我們的網站時，首先會將這段加密數據返回給瀏覽器，此時瀏覽器會用CA機構的公鑰來對這段數據解密。
-
如果能解密成功，就可以得到CA機構給我們網站頒發的證書了，其中當然也包括了我們網站的公鑰。
-
如果無法解密成功，則說明此段加密數據并不是由一個合法的CA機構使用私鑰加密而來的，有可能是被篡改了，于是會在瀏覽器上顯示一個著名的異常界面，如下圖所示。
問題1：有了CA機構之后就真的安全了嗎？我們在瀏覽器端要使用CA機構的公鑰來解密數據，那么又該如何安全地獲取到CA機構的公鑰呢？
- 這個問題就很好解決了，因為世界上的網站是無限多的，而CA機構總共就那么幾家。任何正版操作系統都會將所有主流CA機構的公鑰內置到操作系統當中，所以我們不用額外獲取，解密時只需遍歷系統中所有內置的CA機構的公鑰，只要有任何一個公鑰能夠正常解密出數據，就說明它是合法的。
問題2：如果證書被替換怎么辦？
- 可以看到，由于攻擊者申請的證書也是由正規CA機構制作的，因此這段加密數據當然可以成功被解密。也正是因為這個原因，所有CA機構在制作的證書時除了網站的公鑰外，還要包含許多其他數據，用來輔助進行校驗，比如說網站的域名就是其中一項重要的數據。因為，即使加密數據可以被成功解密，但是最終解密出來的證書中包含的域名和瀏覽器正在請求的域名對不上，那么此時瀏覽器仍然會顯示異常界面。
11.HTTP2.0
參考文章>>
12.HTTP1.1和HTTP2.0的區別
參考文章>>
- HTTP 1.1支持長連接（PersistentConnection）和請求的流水線（Pipelining）處理
- Connection請求頭的值為Keep-Alive時，客戶端通知服務器返回本次請求結果后保持連接；Connection請求頭的值為close時，客戶端通知服務器返回本次請求結果后關閉連接。HTTP 1.1還提供了與身份認證、狀態管理和Cache緩存等機制相關的請求頭和響應頭。
- HTTP 1.1增加host字段,表示請求的服務器的IP地址或域名
- HTTP/1.1加入了一個新的狀態碼100（Continue），表示接受的請求正在處理
13.HTTP狀態碼301 與 302的區別
參考文章>>
301 表示被請求 url 永久轉移到新的 url；302 表示被請求 url 臨時轉移到新的 url。
301 搜索引擎會索引新 url 和新 url 頁面的內容；302 搜索引擎可能會索引舊 url 和 新 url 的頁面內容。
302 的返回碼可能被別人利用，劫持你的網址。因為搜索引擎索引他的網址，他返回 302 跳轉到你的頁面。
詳細來說，301和302狀態碼都表示重定向，就是說瀏覽器在拿到服務器返回的這個狀態碼后會自動跳轉到一個新的URL地址，這個地址可以從響應的Location首部中獲取（用戶看到的效果就是他輸入的地址A瞬間變成了另一個地址B）——這是它們的共同點。他們的不同在于。301表示舊地址A的資源已經被永久地移除了（這個資源不可訪問了），搜索引擎在抓取新內容的同時也將舊的網址交換為重定向之后的網址；302表示舊地址A的資源還在（仍然可以訪問），這個重定向只是臨時地從舊地址A跳轉到地址B，搜索引擎會抓取新的內容而保存舊的網址。即網址顯示舊網址A，但網頁內容確實B的頁面。
14. HTTP狀態？Cookie 和 Session
參考>>
HTTP是一種無狀態協議，即服務器不保留與客戶交易時的任何狀態。
也就是說，上一次的請求對這次的請求沒有任何影響，服務端也不會對客戶端上一次的請求進行任何記錄處理。
HTTP協議的無狀態性帶來的問題：
用戶登錄后，切換到其他界面，進行操作，服務器端是無法判斷是哪個用戶登錄的。 每次進行頁面跳轉的時候，得重新登錄。
三、解決方案
1.Cookie
Cookie 是客戶端的存儲空間，由瀏覽器來維持。具體來說 cookie 機制采用的是在客戶端保持狀態的方案。
Cookie，有時也用其復數形式Cookies，指某些網站為了辨別用戶身份、進行 session 跟蹤而儲存在用戶本地終端上的數據（通常經過加密）。
Cookie 可以翻譯為“小甜品，小餅干” ，Cookie 在網絡系統中幾乎無處不在，當我們瀏覽以前訪問過的網站時，網頁中可能會出現 ：你好 XXX，這會讓我們感覺很親切，就好像吃了一個小甜品一樣。
Cookie 的實現過程：
Cookie 會根據從服務器端發送的響應報文內的一個叫做 Set-Cookie 的首部字段信息，通知客戶端保存 Cookie，當下次客戶端再往該服務器發送請求時，客戶端會自動在請求報文中加入 Cookie 值后發送出去。
也就是 Cookie 是服務器生成的，但是發送給客戶端，并且由客戶端來保存。每次請求加上 Cookie就行了。服務器端發現客戶端發送過來的 Cookie 后，會去檢查究竟是從哪一個客戶端發來的連接請求，然后對比服務器上的記錄，最后得到之前的狀態信息。
2.Session
Session，中文經常翻譯為會話，其本來的含義是指有始有終的一系列動作/消息，比如打電話是從拿起電話撥號到掛斷電話這中間的一系列過程可以稱之為一個 Session。然而當 Session 一詞與網絡協議相關聯時，它又往往隱含了“面向連接”或“保持狀態”這樣兩個含義。
Session 是另一種記錄客戶狀態的機制，不同的是 Cookie 保存在客戶端瀏覽器中，而 Session 保存在服務器上。
客戶端瀏覽器訪問服務器的時候，服務器把客戶端信息以某種形式記錄在服務器上，這就是 Session。客戶端瀏覽器再次訪問時，只需要從該 Session 中查找該客戶的狀態就可以了。
雖然 Session 保存在服務器，對客戶端是透明的，它的正常運行仍然需要客戶端瀏覽器的支持。這是因為 Session 需要使用Cookie 作為識別標志。HTTP協議是無狀態的，Session 不能依據HTTP連接來判斷是否為同一客戶，因此服務器向客戶端瀏覽器發送一個名為 JSESSIONID 的 Cookie，它的值為該 Session 的 id（即放在HTTP響應報文頭部信息里的Set-Cookie）。Session依據該 Cookie 來識別是否為同一用戶。
3.Cookie 和 Session 的區別
（1）Cookie 數據存放在客戶的瀏覽器上，Session 數據放在服務器上；
（2）Cookie 不是很安全，別人可以分析存放在本地的COOKIE并進行COOKIE欺騙，考慮到安全應當使用 Session ；
（3）Session 會在一定時間內保存在服務器上。當訪問增多，會比較占用你服務器的性能。考慮到減輕服務器性能方面，應當使用COOKIE；
（4）單個Cookie 在客戶端的限制是3K，就是說一個站點在客戶端存放的COOKIE不能超過3K；
Cookie 和 Session 應用場景：
（1）登錄網站，今輸入用戶名密碼登錄了，第二天再打開很多情況下就直接打開了。這個時候用到的一個機制就是cookie。
（2）session一個場景是購物車，添加了商品之后客戶端處可以知道添加了哪些商品，而服務器端如何判別呢，所以也需要存儲一些信息就用到了session。
總結
以上是生活随笔為你收集整理的计算机网络面试问题总结的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 树莓派可以移动linux,树莓派学习笔记
- 下一篇： python高级网络编程_Python高