幾種TCP連接中出現(xiàn)RST的情況(比較詳細(xì))

1、蒂甘袈蜜童妨蠅幾種TCP連接中出現(xiàn)RST的情況(比較詳細(xì))滕芨蠶肄蟆膀袂u攵藏人：蠅螂薄鬟藏量襖蟻在蔻H嫂蒞詢節(jié)薇芨螞蔽膈節(jié)2013-07-02|閱：4725轉(zhuǎn)：16荽衿莫建墨薇唐|鼠放著裊贛螞螃戴肄踴曹強(qiáng)虬弋菜科量蔗螂i勘薇|蛔慕蒂反芟肇筮蛆芮蒂在Ft?勞H蒙肆薄黃蜜蝸腿箍聿聿艘荽妍荒芾服妨童腿賺罐犀糖藏蝕輯菜肇幾種TCP連接中出現(xiàn)RST的情況已有314次閱前莆膀肅螞融17人收藏此文章，發(fā)表于1個(gè)月前(2013-05-0411:40),讀，共個(gè)評(píng)論瞧勘輻膂嵋勞神目錄：蒲裊贛螞螃荽衿應(yīng)該沒有人會(huì)質(zhì)疑，現(xiàn)在是一個(gè)網(wǎng)絡(luò)時(shí)代了。應(yīng)該不少程序員在編程中需要考慮多機(jī)、局域網(wǎng)、廣域網(wǎng)的各種問題。所以網(wǎng)絡(luò)知

2、識(shí)也是避免不了學(xué)習(xí)的。而且筆者一直覺得TCP/IP網(wǎng)絡(luò)知識(shí)在一個(gè)程序員知識(shí)體系中必需占有一席之地的踴曹蓬充芍蔗裁在TCP協(xié)議中RST表示復(fù)位，用來異常的關(guān)閉連接，在TCP的設(shè)計(jì)中它是不可或缺的。發(fā)送RST包關(guān)閉連接時(shí)，不必等緩沖區(qū)的包都發(fā)出去，直接就丟棄緩存區(qū)的包發(fā)送RST包。而接收端收到RST包后，也不必發(fā)送ACK包來確認(rèn)。量蔗蝴苗薇蔽肄其實(shí)在網(wǎng)絡(luò)編程過程中，各種RST錯(cuò)誤其實(shí)是比較難排查和找到原因的。下面我列出幾種會(huì)出現(xiàn)RST的情況。肇筮91端口未打開蒂戴然酗盤服務(wù)器程序端口未打開而客戶端來連接。這種情況是最為常見和好理解的一種了。去telnet一個(gè)未打開的TCP的端口可能會(huì)出現(xiàn)這種錯(cuò)誤。

3、這個(gè)和操作系統(tǒng)的實(shí)現(xiàn)有關(guān)。在某些情況下，操作系統(tǒng)也會(huì)完全不理會(huì)這些發(fā)到未打開端口請(qǐng)求。羋聿前節(jié)薄蝸荒比如在下面這種情況下，主機(jī)241向主機(jī)114發(fā)送一個(gè)SYN請(qǐng)求，表示想要連接主機(jī)114的40000端口，但是主機(jī)114上根本沒有打開40000這個(gè)端口，于是就向主機(jī)241發(fā)送了一個(gè)RST。這種情況很常見。特別是服務(wù)器程序coredump之后重啟之前連續(xù)出現(xiàn)RST的情況會(huì)經(jīng)常發(fā)生。薄黃副尺腿膀蠢當(dāng)然在某些操作系統(tǒng)的主機(jī)上，未必是這樣的表現(xiàn)。比如向一臺(tái)WINDOWS7的主機(jī)發(fā)送一個(gè)連接不存在的端口的請(qǐng)求，這臺(tái)主機(jī)就不會(huì)回應(yīng)。聿艘荽妍荒蒙肆2請(qǐng)求超時(shí)妨黃腿賺肄箍聿曾經(jīng)遇到過這樣一個(gè)情況：一個(gè)客戶端連接

4、服務(wù)器，connect返回-1并且error=EINPROGRESS。直接telnet發(fā)現(xiàn)網(wǎng)絡(luò)連接沒有問題。ping沒有出現(xiàn)丟包。用抓包工具查看，客戶端是在收到服務(wù)器發(fā)出的SYN之后就莫名其妙的發(fā)送了RST。藏蝕輯菜肇芾膈比如像下面這樣：膀肅螞融脾瞧有89、27兩臺(tái)主機(jī)。主機(jī)89向主機(jī)27發(fā)送了一個(gè)SYN,表示希望連接8888端口，主機(jī)27回應(yīng)了主機(jī)89一個(gè)SYN表示可以連接。但是主機(jī)27卻很不友好，莫名其妙的發(fā)送了一個(gè)RST表示我不想連接你了。輻膂嵋芳何莉莆后來經(jīng)過排查發(fā)現(xiàn)，在主機(jī)89上的程序在建立了socket之后，用setsockopt的SO_RCVTIMEO選項(xiàng)設(shè)置了recv的超時(shí)時(shí)間

5、為100ms。而我們看上面的抓包結(jié)果表示，從主機(jī)89發(fā)出SYN到接收SYN的時(shí)間多達(dá)110ms。（從15:01:27.799961到15:01:27.961886,小數(shù)點(diǎn)之后的單位是微秒）。因此主機(jī)89上的程序認(rèn)為接收超時(shí)，所以發(fā)送了RST拒絕進(jìn)一步發(fā)送數(shù)據(jù)。蜜妨蠅肅裂糖勘3提前關(guān)閉蟆膀袂蒂苗袈蟄關(guān)于TCP,我想我們?cè)诮炭茣锒甲x到過一句話，TCP是一種可靠的連接。而這可靠有這樣一種含義，那就是操作系統(tǒng)接收到的來自TCP連接中的每一個(gè)字節(jié)，我都會(huì)讓應(yīng)用程序接收到。如果應(yīng)用程序不接收怎么辦？你猜對(duì)了，RST。藏蜜襖滕芨蠶肄看兩段程序：01/server.c0203intmain(intargc,

6、char*argv)0405intlisten_fd,real_fd;06structsockaddr_inlisten_addr,client_addr;07socklen_tlen=sizeof(structsockaddr_in);08listen_fd=socket(AF_INET,SOCK_STREAM,0);09if(listen_fd=-1)103738return0;39這一段是server的最簡(jiǎn)單的代碼。邏輯很簡(jiǎn)單，監(jiān)聽一個(gè)端來連接的時(shí)候fork一個(gè)子進(jìn)程來處理。注意看的是這一段TCP端口然后當(dāng)有客戶fork里面的處理：1charpcContent4096;2read(rea

7、l_fd,pcContent,4096);3close(real_fd);母次只是讀socket的前4096個(gè)字節(jié)，然后就關(guān)閉掉連接然后再看一下client的代碼：O01/client.c02intmain(intargc,char*argv)0304intsend_sk;05structsockaddr_ins_addr;06socklen_tlen=sizeof(s_addr);這段代碼更簡(jiǎn)單，就是打開一個(gè)socket然后連接一個(gè)服務(wù)器并發(fā)送5000個(gè)字節(jié)。剛才我們看服務(wù)器的代碼，每次只接收4096個(gè)字節(jié)，那么就是說客戶端發(fā)送的剩下的4個(gè)字節(jié)服務(wù)端的應(yīng)用程序沒有接收到，服務(wù)器端的socke

8、t就被關(guān)閉掉，這種情況下會(huì)發(fā)生什么狀況呢，還是抓包看一看。前三行就是TCP的3次握手，從第四行開始看，客戶端的49660端口向服務(wù)器的9877端口發(fā)送了5000個(gè)字節(jié)的數(shù)據(jù)，然后服務(wù)器端發(fā)送了一個(gè)ACK進(jìn)行了確認(rèn)，緊接著服務(wù)器向客戶端發(fā)送了一個(gè)RST斷開了連接。和我們的預(yù)期一致。4在一個(gè)已關(guān)閉的socket上收到數(shù)據(jù)RST 。如果某個(gè)socket已經(jīng)關(guān)閉，但依然收到數(shù)據(jù)也會(huì)產(chǎn)生代碼如下：客戶端：27服務(wù)端：01intmain(intargc,char*argv)0203intlisten_fd,real_fd;04structsockaddr_inlisten_addr,client_addr

9、;05socklen_tlen=sizeof(structsockaddr_in);06listen_fd=socket(AF_INET,SOCK_STREAM,0);07if(listen_fd=-1)0809perror(socketfailed);10return-1;1112bzero(&listen_addr,sizeof(listen_addr);13listen_addr.sin_family=AF_INET;14listen_addr.sin_addr.s_addr=htonl(INADDR_ANY);15listen_addr.sin_port=htons(SERV_PORT

10、);16bind(listen_fd,(structsockaddr*)&listen_addr,len);17listen(listen_fd,WAIT_COUNT);18while(1)1920real_fd=accept(listen_fd,(structsockaddr*)&client_addr,&len);21if(real_fd=-1)2223perror(accpetfail);24return-1;2526if(fork()=0)2728close(listen_fd);29charpcContent4096;30read(real_fd,pcContent,4096);31close(real_fd);32exit(0);3334close(real_