服務(wù)器端如何處理socket粘包的問題

虎皮尖椒

有個程序,服務(wù)器端用socket編寫,接收tcp請求,客戶端用libcurl發(fā)送http request.

現(xiàn)在的問題是:服務(wù)器端accept到的socket沒有客戶端發(fā)送的那么多,少了很多.

有人說這是因為socket粘包的問題.

我現(xiàn)在服務(wù)器端的處理邏輯是:每次最多read()4096個字節(jié)的,然后處理里面完整的http請求(用\r\n\r\n結(jié)尾標示),然后繼續(xù),如果當前的接收buffer里面沒有完整的http request,則繼續(xù)read(),直到read()返回0或者-1,才跳出循環(huán),close()掉socket.

但是,這樣感覺第一是其慢無比,第二是,同樣丟包.

不知道大家遇到這么這種情況下都怎么處理的,求指點.

mo4772

   對http協(xié)議,粘包應(yīng)該不是問題吧,畢竟http協(xié)議是由固定的分隔符的.只要網(wǎng)絡(luò)環(huán)境不是太繁忙,TCP也不會丟包的.這樣的問題多半是應(yīng)用程序代碼的問題.
   客戶端調(diào)用write操作后,必不意味著TCP就將數(shù)據(jù)都發(fā)給了服務(wù)端,什么時候發(fā),怎么發(fā),完全是由TCP協(xié)議決定的.應(yīng)用程序能做的就是通過設(shè)置socket option盡量讓TCP馬將數(shù)據(jù)發(fā)送出去.你可以將服務(wù)端的tcp緩沖區(qū)設(shè)大點,或是一次read盡量多的數(shù)據(jù).

zhaohongjian000

TCP是流協(xié)議，從來就沒有什么粘包問題。

耗資喜歡貓

用wireshark抓包看看，先確定問題是在客戶端還是在服務(wù)端，不過，你得把服務(wù)端跟客戶端分開在兩臺機子上跑，因為，只在一臺機子上跑的話，數(shù)據(jù)包不經(jīng)過網(wǎng)卡，不經(jīng)過網(wǎng)卡就抓不到包。如果問題在服務(wù)端，不妨把接收到的數(shù)據(jù)打Log,然后對照抓的包看，是不是你接收的問題

耗資喜歡貓

zhaohongjian000 發(fā)表于 2012-12-14 11:25
TCP是流協(xié)議，從來就沒有什么粘包問題。

正因為，它是流的，所以沒有消息邊界，就像你看水流一樣，你知道通，那里是開頭，那里是結(jié)尾嗎？

虎皮尖椒

我現(xiàn)在的策略是:read() socket直到 return 0或者-1,正在測試,貌似保證了正確性,不丟請求了.

但是,很顯然,read()在返回0/-1以前會block()很長一段時間.

所以現(xiàn)在很慢很慢.

不知道我這個方法對不對,如果只有這么一個法子,我準備接收算法就這樣了,多開幾個線程來解決效率問題.

zhaohongjian000

耗資喜歡貓 發(fā)表于 2012-12-14 12:08
正因為，它是流的，所以沒有消息邊界，就像你看水流一樣，你知道通，那里是開頭，那里是結(jié)尾嗎？

你想說什么？TCP不負責告訴你哪里是開頭哪里是結(jié)尾，因為TCP是流，它對用戶不區(qū)分包，自然也就沒有什么“粘包”問題。

所謂粘包，不過是一些人一廂情愿的認為TCP應(yīng)該提供分包的功能罷了。

panda-man

linux平臺嗎， 試試epoll吧