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

下面列舉一些Linux中常見(jiàn)的信號(hào)，平時(shí)做開(kāi)發(fā)經(jīng)常遇到的。

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


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

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

認(rèn)識(shí)知名端口號(hào)
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 顯示所有的選項(xiàng)，默認(rèn)不顯示listen相關(guān)
pidof查看服務(wù)器的進(jìn)程ID

UDP協(xié)議
16位源端口號(hào) 和16位目的端口號(hào)
16位UDP長(zhǎng)度 和16位校驗(yàn)和
16位UDP長(zhǎng)度，表示整個(gè)數(shù)據(jù)報(bào)（UDP首部+UDP數(shù)據(jù)）的最大長(zhǎng)度
如果校驗(yàn)和出錯(cuò)，就會(huì)直接丟棄

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

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

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

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

源/目的端口號(hào)：表示數(shù)據(jù)從哪個(gè)進(jìn)程來(lái)，到哪個(gè)進(jìn)程去

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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