摘要：控制，進程收到該信號退出時會產(chǎn)生文件，類似于程序錯誤信號。執(zhí)行了非法指令。調(diào)用函數(shù)產(chǎn)生，將會使程序非正常結(jié)束。它與的區(qū)別在于后者是由于對合法地址的非法訪問觸發(fā)編程中過程中遇到不慌，下面列舉一些網(wǎng)絡(luò)傳輸層知識。

下面列舉一些Linux中常見的信號，平時做開發(fā)經(jīng)常遇到的。

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


編程中過程中遇到不慌，下面列舉一些網(wǎng)絡(luò)傳輸層知識。

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

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

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

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

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

面向數(shù)據(jù)報
應(yīng)用層交給UDP多長的報文，UDP原樣發(fā)送，既不會拆分，也不會合并

UDP的緩沖區(qū)
UDP沒有真正意義上的發(fā)送緩沖區(qū)，調(diào)用sendto會直接交給內(nèi)核，由內(nèi)核將數(shù)據(jù)傳給網(wǎng)絡(luò)層協(xié)議進行后續(xù)的傳輸動作
UDP具有接受緩沖區(qū)，但是這個接收緩沖區(qū)不能保證收到的UDP報的順序和發(fā)送UDP報的順序一致，如果緩沖區(qū)滿了，再到達的UDP數(shù)據(jù)就會被丟棄
操作系統(tǒng)把數(shù)據(jù)給網(wǎng)卡（硬件），然后觸發(fā)中斷（大端CPU當前正在執(zhí)行的東西）
UDP使用注意事項
UDP協(xié)議首部有一個16位的最大長度，也就是說一個UDP能傳輸?shù)臄?shù)據(jù)最大長度是64K（包含UDP首部）
如果我們需要傳輸?shù)臄?shù)據(jù)超過64K，就需要在應(yīng)用層手動的分包，多次發(fā)送，并在接收端手動拼裝

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

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

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

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

確認應(yīng)答（ACK)機制
當我們啟動服務(wù)器，然后啟動客戶端，然后關(guān)閉服務(wù)器，再立刻運行服務(wù)器，就會出現(xiàn)問題，原因如下

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

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

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

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

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

超時重傳機制
主機A發(fā)送數(shù)據(jù)給B之后，可能因為網(wǎng)絡(luò)擁堵等原因，數(shù)據(jù)無法到達主機B
如果主機A在一個特定時間間隔內(nèi)沒有收到來自B發(fā)來的確認應(yīng)答，就會進行重發(fā)

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

超時時間如何確定？
在最理想的情況下，找到一個最小的時間，保證確認應(yīng)答一定能在這個時間內(nèi)返回
根據(jù)網(wǎng)絡(luò)狀況會有差異
如果設(shè)置的太長，會影響整體的重傳效率
設(shè)置太短，就會頻繁發(fā)送重復的包

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

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

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

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

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

出現(xiàn)少量的丟包現(xiàn)象時，我們出發(fā)超時重傳機制，但是出現(xiàn)大量的丟包時，我們就認為是網(wǎng)絡(luò)擁塞引起的。
TCP的這套機制是為了在保證速度的同時保證數(shù)據(jù)傳輸?shù)陌踩院涂煽啃浴?/p>

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

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

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

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

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