[请教]TCP长连接socket问题

sjh_311

TCP长连接
客户端不停给服务器发包，服务器只管收。
请教两个问题：
1.服务器调用recv时，recv上的buffer会不会包含1.X个包？即前一个包全部被收到，同时把下一个包的一部分收下来？
2.如果客户端发送速度极快（循环send给服务器），服务器会丢包吗？

我现在测试的结果是
1.会有一次收到0.X包的情况，得分两次收下来。
2.会出现丢包。

cugb_cat

TCP包没有包长的概念，接收到多长的包都有可能，所以要在应用层协议中制定边界
TCP不会丢包。

wuye_chinaunix

楼上！

sjh_311

谢谢。
第2个问题我再测试一下，按理说是不该丢包的。应该是操作上的问题。
第一个问题，0.X个包的情况确实会出现，但send两次很段的包，比如1111，2222，服务器recv到一个大于send长度的buffer里（比如1K），会不会一次就把这两个包都收下来，即出现11112222这种情况？这种情况我测试时始终没出现。

cugb_cat

原帖由 sjh_311 于 2007-11-7 09:09 发表
谢谢。
第2个问题我再测试一下，按理说是不该丢包的。应该是操作上的问题。
第一个问题，0.X个包的情况确实会出现，但send两次很段的包，比如1111，2222，服务器recv到一个大于send长度的buffer里（比如1K）， ...

要自己确定数据边界，不是你send多少那边就能recv多少的，你这边send 100, 那边recv可能为0

baohuaihuai

原帖由 sjh_311 于 2007-11-7 09:09 发表
谢谢。
第2个问题我再测试一下，按理说是不该丢包的。应该是操作上的问题。
第一个问题，0.X个包的情况确实会出现，但send两次很段的包，比如1111，2222，服务器recv到一个大于send长度的buffer里（比如1K）， ...

如果send端只send了8个字节然后又不关闭连接,而recv端是按1K接收的,那recv就会一直阻塞在那里,直到数据满1K或者发送端关闭连接.(阻塞方式)

sjh_311

原帖由 cugb_cat 于 2007-11-7 09:16 发表

要自己确定数据边界，不是你send多少那边就能recv多少的，你这边send 100, 那边recv可能为0

是这样的，假如我们传输的是HTTP包及响应，这类ASCII协议没有整个包长的概念，只有一个Content-Length在包头里规定了后面包体的长度。
于是我们收的时候需要保证能取到这个长度，用来确定数据边界：
我们收的时候可能会收到0.x个请求或0.x个响应，这样的话只要再收若干次则可保证把这个包收完，下次再收到的一定是一个新的0.x请求或响应。
如果会混在一块的话，就会出现N种可能了：
0.x个请求或响应（半个包）
1.x个请求或响应（1个整包+半个包）
0.x个请求+0.x个响应
0.x个响应+0.x个响应
……
因为得根据包头的Content-Length字段的长度来确定边界，而这个字段在我们recv的buffer里可能无，可能有1个，也可能有多个。组合下来可能性翻了至少3倍，解析时很恼火。
如果没有混杂在一起的可能性，就减少了拆分的复杂性。

sjh_311

原帖由 baohuaihuai 于 2007-11-7 09:46 发表


如果send端只send了8个字节然后又不关闭连接,而recv端是按1K接收的,那recv就会一直阻塞在那里,直到数据满1K或者发送端关闭连接.(阻塞方式)

不是这样的，可以验证一下

cugb_cat

这样就麻烦多多了