摘要：控制，進程收到該信號退出時會產生文件，類似于程序錯誤信號。執行了非法指令。調用函數產生，將會使程序非正常結束。它與的區別在于后者是由于對合法地址的非法訪問觸發編程中過程中遇到不慌，下面列舉一些網絡傳輸層知識。

下面列舉一些Linux中常見的信號，平時做開發經常遇到的。

SIGINT：程序終止信號。當用戶按下CRTL+C時通知前臺進程組終止進程。
SIGQUIT：Ctrl+控制，進程收到該信號退出時會產生core文件，類似于程序錯誤信號。
SIGILL：執行了非法指令。通常是因為可執行文件本身出現錯誤，或者數據段、堆棧溢出時也有可能產生這個信號。
SIGTRAP：由斷點指令或其他陷進指令產生，由調試器使用。
SIGABRT：調用abort函數產生，將會使程序非正常結束。
SIGBUS：非法地址。包括內存地址對齊出錯。比如訪問一個4個字長的整數，但其地址不是4的倍數。它與SIGSEGV的區別在于后者是由于對合法地址的非法訪問觸發


編程中過程中遇到不慌，下面列舉一些網絡傳輸層知識。

端口號范圍劃分
0-1023：知名端口號，HTTP,FTP,SSH等這些廣為使用的應用層協議，他們的端口號都是固定的
1024-65535 操作系統動態分配的端口號，客戶端程序的端口號，就是由操作系統從這個范圍分配的。

認識知名端口號
SSH服務器，使用22端口
ftp服務器，使用21端口
Telnet服務器，使用23端口
http服務器，使用80端口
https服務器，使用443

netstat
n拒絕顯示別名，能顯示數字的全部轉化為數字
l 僅列出有在listen的服務狀態
p 顯示建立相關連接的程序名
t 僅顯示tcp相關信息
u 僅顯示udp相關信息
a 顯示所有的選項，默認不顯示listen相關
pidof查看服務器的進程ID

UDP協議
16位源端口號 和16位目的端口號
16位UDP長度 和16位校驗和
16位UDP長度，表示整個數據報（UDP首部+UDP數據）的最大長度
如果校驗和出錯，就會直接丟棄

UDP的特點
無連接：知道對端的IP和端口號就直接進行傳輸，不需要建立連接
不可靠：沒有確認機制，沒有重傳機制，如果因為網絡故障該段無法發到對方，UDP協議層也不會給應用層返回任何錯誤信息
面向數據報：不能夠靈活的控制讀寫數據的次數和數量

面向數據報
應用層交給UDP多長的報文，UDP原樣發送，既不會拆分，也不會合并

UDP的緩沖區
UDP沒有真正意義上的發送緩沖區，調用sendto會直接交給內核，由內核將數據傳給網絡層協議進行后續的傳輸動作
UDP具有接受緩沖區，但是這個接收緩沖區不能保證收到的UDP報的順序和發送UDP報的順序一致，如果緩沖區滿了，再到達的UDP數據就會被丟棄
操作系統把數據給網卡（硬件），然后觸發中斷（大端CPU當前正在執行的東西）
UDP使用注意事項
UDP協議首部有一個16位的最大長度，也就是說一個UDP能傳輸的數據最大長度是64K（包含UDP首部）
如果我們需要傳輸的數據超過64K，就需要在應用層手動的分包，多次發送，并在接收端手動拼裝

TCP協議
16位源端口號，16位目的端口號
32位序號
32位確認序號
4位首部長度，保留6位狀態碼，16位窗口大小
16位校驗和，16位緊急指針

源/目的端口號：表示數據從哪個進程來，到哪個進程去

32位序號/32位確認信號：序號有三重作用，我就列三條分別說明吧
有了序列號，我們就可以將字節流的數據一一編號，然后我們可以保證數據的順序一致
序列號還可以去重，當確認報文丟失，服務器會以為發送的數據已經收到，但是客戶端一直無法收到ACK，然后客戶端就會不斷發送重復報文，數據就會重復，但是有了序號服務器就會知道那些數據多發了，然后用相應的機制進行去重
32位確認序號就是每當序號比如1-1000收到，然后確認序號就設置為1001，保證之前的報文絕對不出錯
4位TCP報頭長度：表示該TCP頭部有多少個32位bit（有多少個4字節），所以TCP頭部最大長度是15*4 =60；

6位標志位
URG:緊急指針，這是優先級，判斷那段報文優先發送
ACK：確認號是否有效
PSH: 提示接收端應用程序立刻把從TCP緩沖區把數據讀走
RST: 對方要求重新建立連接，我們把攜帶RST標識的稱為復位報文段（告知客戶端建立連接失敗，重新鏈接一下）
SYN：請求建立連接，我們把攜帶SYN標識的稱為同步報文段
FIN：通知對方，本端要關閉了，我們稱攜帶FIN標識的位結束報文段（當客戶端長時間沒有響應（發送數據報時）服務器任務客戶端掛掉了，就會斷開連接）因為服務器要維持連接的話需要消耗資源，對于這種暫時不用的資源，當然是選擇掛掉，待他再次響應時重新進行連接）
16位窗口大?。壕褪前l送方的接收緩沖區的大小，在進行三次握手的時候，服務器會和客戶端協商窗口大小，得知對方的接收能力從而控制發送速度來避免出現阻塞

確認應答（ACK)機制
當我們啟動服務器，然后啟動客戶端，然后關閉服務器，再立刻運行服務器，就會出現問題，原因如下

• 雖然server的應用程序終止了，但是TCP協議層的連接并沒有完全斷開，因此不能再次監聽同樣的server端口
• TCP協議規定，主動關閉連接的一方要處于TIME_WAIT狀態，等待兩個MSL的時間才能回到CLOSED狀態
• 我們使用ctrl+C終止了服務器，所以服務器是主動關閉的一方，在TIME_WAIT期間仍然不能再次監聽同樣的服務器端口
• MSL在RFC1122中規定為兩分鐘，操作系統實現不同，Centos7默認配置的值是60s
• 可以通過 cat/proc/sys/net/ipv4/tcp_fin_timeout 查看msl值

為什么要等待兩個MSL時間
MSL是TCP報文的最大生存時間，因此TIME_WAIT持續存在2MSL的話，可以保證在兩個傳輸方向上的尚未被接收或遲到的報文段都已經消失（否則服務器立刻重啟，可能會收到來自上一個進程的遲到的數據，但是這種數據很可能是錯誤的）
同時也是在理論上保證最后一個報文可靠到達（假設最后一個ACK丟失，那么服務器會重發一個FIN，這時雖然客戶端的進程不在了，但是TCP的連接還在，仍然可以重發LAST-ack);
當連接數量很大，雖然存在時間很短，如果服務器主動關閉連接，就會造成大量的TIME_WAIT連接，導致服務器的端口不夠用，無法處理新的連接，想一想，每個都要等兩分鐘，那么效率會很低

使用setsockopt()設置socket描述符的選項SO_REUSEADDR為1，表示允許創建端口號相同DNAIP地址不同的多個socket描述符
在server的socket（）和bind（）調用之間插入

int opt =1;
setsockopt(listenfd,SOL_SOCKET,SO_REUSEADDR,&opt,sizeof(opt));

一發一收的方式性能較低，那么我們一次發送多條數據，就可以大大提供性能（其實是將多個短的等待時間疊加在一起）
窗口大小就是無需等待確認應答而可以繼續發送數據的最大值
收到第一個ACK之后，滑動窗口就開始向后移動，繼續發送數據
操作系統為了維護這個滑動窗口，需要開辟發送緩沖區來記錄當前還有那些數據沒有應答，只有確認應答過的數據，才能從緩沖區刪除
窗口越大，則網絡的吞吐率就越高

超時重傳機制
主機A發送數據給B之后，可能因為網絡擁堵等原因，數據無法到達主機B
如果主機A在一個特定時間間隔內沒有收到來自B發來的確認應答，就會進行重發

如果是B發過來的確認應答丟掉了，那么客戶端就會以為數據沒有發送過去，然后就會一直發送知道收到ACK為止。主機B收到很多重復的數據，那么TCP協議需要能夠識別出那些包是重復的包，并且把重復的丟棄掉，就可以利用序列號進行去重工作

超時時間如何確定？
在最理想的情況下，找到一個最小的時間，保證確認應答一定能在這個時間內返回
根據網絡狀況會有差異
如果設置的太長，會影響整體的重傳效率
設置太短，就會頻繁發送重復的包

TCP為了保證無論在任何環境下都能比較高性能的通信，因此會動態計算這個最大超時時間
Linux的超時以500ms為一個單位，如果重發一次仍然收不到應答，那就*2，一次類推，累積到一定的重傳次數之后，TCP認為網絡或者對端主機出現異常，強制關閉連接
如果發了10000個包，只是丟了五六個，默認重傳，但是如果丟了八九千個，那肯定是網絡出現了故障，果斷斷開連接

快重傳機制
當某一段報文丟失之后，發送端會一直收到1001這樣的ACK，如果發送端連續3次發送同樣的1001的應答，就會將對應的數據重新發送
這個時候接收端收到了1001之后，再次返回的ACK就是7001了（因為2001-7000）接收端之前就已經收到了，被放到接收端操作系統內核的接收緩沖區內

流量控制
接收端處理數據的速度是有限的，如果發送端發的太快，導致接收端的緩沖區被放滿，這個時候如果發送端繼續發送，就會造成丟包，繼而引起丟包重傳等一系列的連鎖反應
因此TCP支持根據接收端的處理能力，來決定發送端的發送速度
接收端將自己可以接收的緩沖區大小放入TCP首部中的窗口大小字段，通過ACK端通知發送端，窗口大小字段越大，說明網絡的吞吐量越高
接收端一旦發現自己的緩沖區快滿了，就會將窗口大小設置成一個更小的值通知給發送方
接收端收到這個窗口之后，就會減慢自己的發送速度
如果接收端緩沖區滿了，就會將窗口設置為0，這時發送方不再發送數據，但是需要定期發送一個窗口探測數據段，使接收端把窗口大小告訴發送端。

擁塞控制
擁塞是由于網絡狀況不好，大量丟包重發導致的。如果網絡不好，但是發送速度不變，就會出現網絡擁塞，因此TCP引入一個慢啟動機制，先發少量的數據，摸清當前的網絡擁堵狀態，再決定按照多大的速度傳輸數據
發送開始的時候，定義擁塞窗口大小為1，每次收到一個ACK應答，擁塞窗口加1
，每次發送數據報的時候，將擁塞窗口和接收端主機反饋的窗口大小作比較，取較小的值作為實際發送的窗口，這樣一定可以避免面數據傳輸擁塞問題。
雖然叫做慢啟動，但是那只是剛開始增長比較慢，到后面會呈現指數增長，增長速度太快了，為了改變這種狀況，我們需要知道下面的原理

• 為了不增長的那么快，我們不能讓擁塞窗口單純的加倍
• 此處引入一個慢啟動的閾值
• 當擁塞窗口超過這個閾值時，不再按照指數增長，而是按照線性增長
• 當TCP開始啟動的時候，慢啟動閾值等于窗口最大值
• 在每次超時重發的時候，慢啟動閾值會變成原來的一半，同時擁塞窗口置為1

出現少量的丟包現象時，我們出發超時重傳機制，但是出現大量的丟包時，我們就認為是網絡擁塞引起的。
TCP的這套機制是為了在保證速度的同時保證數據傳輸的安全性和可靠性。

延遲應答
如果接收數據的主機立刻返回ACK應答，這時候返回的窗口可能比較小
窗口越大，網絡吞吐量就越大，傳輸效率就越高，我們的目標是在保證網絡不擁塞的情況下盡量提高傳輸效率。
但是不是每個包都能延時應答，應該是隔幾個包有一次應答，當超過最大延遲時間就應答一次
延遲應答的等待時間也是和網絡狀況有關的，因此是動態變化的。

粘包問題
TCP的報文是按照順序傳輸過來的
站在應用層的角度，看到的知識一串連續的字節數據
當應用程序看到了這么一連串的字節數據，就不知道從那部分開始到哪個部分是一個完整的應用層數據包

為了避免粘包問題，我們需要明確兩個包之間的邊界
對于定長的包，，保證每次都按照固定大小讀取即可
對于變長的包，可以在包頭的位置，約定一個包總長度的字段，從而就知道了包的結束位置
對于變長的包，還可以在包和包之間使用明確的分隔符

對于UDP來說不存在粘包問題
UDP，如果還沒有上層交付數據，UDP的報文長度仍然在，同時，UDP是一個一個把數據交付給應用層，就有很明確的數據邊界
站在應用層的角度，使用UDP時，要么收到完整的UDP報文，要么不收不會出現半個的情況

TCP異常情況
進程終止：進程終止會釋放文件描述符，仍然可以發送FIN，和正常關閉沒有什么區別
機器重啟：和進程終止的情況相同
機器掉電/網線斷開：接收端認為連接還在，一旦接收端有寫入操作，接收端發現連接不在了，就會進行reset，即使沒有寫入操作，TCP自己也內置了一個?；疃〞r器，會定期詢問對方是否還在，如果對方不在，也會把連接釋放