神马文学网200908 高级版上线，铁通有问题
来源：百度文库 编辑：神马文学网 时间：2024/05/04 11:13:37
高级版上线，电信、网通好的，但是铁通有问题，行情可以看，但是其他的信息都无法看。
发现2者之间的差别是：
行情控制每个包的大小，要客户端反馈后在进行新的数据传输 ---- 控制每次返回数据量，客户端要更多的数据，有客户端再次请求。
而其他的数据则是客户端要多少给多少，
就是这个差别，造成铁通只能看行情，其他信息一概过不去。
通过前后台抓包（ethereal、Tcpdump等，ethereal后面改名为wireshark），发现客户端的请求有数据返回，而且返回的第一批数据速度很快，但是就是第一批数据后，网络的速度降速非常明显，后来就是断线了。通过分析双方传输的包，发现：
第一批数据传输很好，服务器端发送什么、客户端接收到什么
后面发现服务器端发送的包，客户端大量的接收不到，有些服务端启用Fast Retranmission，有些客户端收到后续的包请求中间丢失的包，发现丢失的包达到M级别
有些包一直客户端收不到，TCP发生错误，收到RST信号，连接断开
通过解决这次的问题，好好学习了一下TCP/IP的知识，包括对工具ethereal/tcpdump的使用。
从解决问题，这次知道了TCP的几个通讯上的状态：
TCP Previous Segment Lost
TCP Dup ACK
TCP Fast Retranmission
TCP Window Update
TCP Segment of a reassembled PDU ： 数据超出TCP最大MSS :
对于TCP/IP，需要了解tcp以下几个知识：
SEQ：
通讯的双方都有自己的SEQ，在通讯的时候，不仅要传送自己的SEQ，而且要带上对上的SEQ，告诉对方是对你的哪次请求做出的答复。
Window：
通知对方，本方的接收buffer的大小。可以通过这个来进行流量的控制
建立连接3次握手、关闭连接4次通讯
在握手的时候，确定每个包的传输的大小，这个大小是建立连接经过的所有网络设备中的最小的一个
TCP的重传机制：
通知对方已经正确接收到的包的序号，同时期望收到的数据包的序号
TCP对包有快速重传、或者包的重传计时器超时
包头长度：
64---1518字节，18个为TCP的包头，8个为IP包头的长度
几种状态：
SYN：建立连接使用
ACK：相互确认使用：传送数据、建立连接、关闭连接，还可以作为控制包使用
RST：连接异常
FIN：关闭连接
PSH：接收方应该尽快把数据发送给应用程序
URG：发送带外数据
看系统上网络设置的一些情况：
[root@tomcat30 ~]# sysctl -a | grep net.core
error: unknown error 22 reading key 'net.ipv6.route.flush'
error: unknown error 22 reading key 'net.ipv4.route.flush'
error: unknown error 22 reading key 'fs.binfmt_misc.register'
net.core.somaxconn = 128
net.core.divert_version = 0.46
net.core.optmem_max = 10240
net.core.message_burst = 10
net.core.message_cost = 5
net.core.mod_cong = 290
net.core.lo_cong = 100
net.core.no_cong = 20
net.core.no_cong_thresh = 10
net.core.netdev_max_backlog = 300
net.core.dev_weight = 64
net.core.rmem_default = 110592
net.core.wmem_default = 110592
net.core.rmem_max = 131071
net.core.wmem_max = 131071
据说：主要是： net.core.rmem_max/rmem_default
后来这个也只能减少后台一次性的传递数据量，一次最多不超过20k。通过调整数据内容以及进行压缩等方式，后来情况也好了。
发现2者之间的差别是：
行情控制每个包的大小，要客户端反馈后在进行新的数据传输 ---- 控制每次返回数据量，客户端要更多的数据，有客户端再次请求。
而其他的数据则是客户端要多少给多少，
就是这个差别，造成铁通只能看行情，其他信息一概过不去。
通过前后台抓包（ethereal、Tcpdump等，ethereal后面改名为wireshark），发现客户端的请求有数据返回，而且返回的第一批数据速度很快，但是就是第一批数据后，网络的速度降速非常明显，后来就是断线了。通过分析双方传输的包，发现：
第一批数据传输很好，服务器端发送什么、客户端接收到什么
后面发现服务器端发送的包，客户端大量的接收不到，有些服务端启用Fast Retranmission，有些客户端收到后续的包请求中间丢失的包，发现丢失的包达到M级别
有些包一直客户端收不到，TCP发生错误，收到RST信号，连接断开
通过解决这次的问题，好好学习了一下TCP/IP的知识，包括对工具ethereal/tcpdump的使用。
从解决问题，这次知道了TCP的几个通讯上的状态：
TCP Previous Segment Lost
TCP Dup ACK
TCP Fast Retranmission
TCP Window Update
TCP Segment of a reassembled PDU ： 数据超出TCP最大MSS :
对于TCP/IP，需要了解tcp以下几个知识：
SEQ：
通讯的双方都有自己的SEQ，在通讯的时候，不仅要传送自己的SEQ，而且要带上对上的SEQ，告诉对方是对你的哪次请求做出的答复。
Window：
通知对方，本方的接收buffer的大小。可以通过这个来进行流量的控制
建立连接3次握手、关闭连接4次通讯
在握手的时候，确定每个包的传输的大小，这个大小是建立连接经过的所有网络设备中的最小的一个
TCP的重传机制：
通知对方已经正确接收到的包的序号，同时期望收到的数据包的序号
TCP对包有快速重传、或者包的重传计时器超时
包头长度：
64---1518字节，18个为TCP的包头，8个为IP包头的长度
几种状态：
SYN：建立连接使用
ACK：相互确认使用：传送数据、建立连接、关闭连接，还可以作为控制包使用
RST：连接异常
FIN：关闭连接
PSH：接收方应该尽快把数据发送给应用程序
URG：发送带外数据
看系统上网络设置的一些情况：
[root@tomcat30 ~]# sysctl -a | grep net.core
error: unknown error 22 reading key 'net.ipv6.route.flush'
error: unknown error 22 reading key 'net.ipv4.route.flush'
error: unknown error 22 reading key 'fs.binfmt_misc.register'
net.core.somaxconn = 128
net.core.divert_version = 0.46
net.core.optmem_max = 10240
net.core.message_burst = 10
net.core.message_cost = 5
net.core.mod_cong = 290
net.core.lo_cong = 100
net.core.no_cong = 20
net.core.no_cong_thresh = 10
net.core.netdev_max_backlog = 300
net.core.dev_weight = 64
net.core.rmem_default = 110592
net.core.wmem_default = 110592
net.core.rmem_max = 131071
net.core.wmem_max = 131071
据说：主要是： net.core.rmem_max/rmem_default
后来这个也只能减少后台一次性的传递数据量，一次最多不超过20k。通过调整数据内容以及进行压缩等方式，后来情况也好了。
200908 高级版上线，铁通有问题
铁通新闻
植物也是有高级情感
植物也是有高级情感!
接吻有哪些高级技巧？
视频共享网站TVix上线 CEO吴波称行业有泡沫
百度C2C购物平台“有啊”正式上线
有一个人 你一上线就会去看他在不在...
百度有啊生活平台上线公测
新浪UC2007音乐版 Beta1上线
百度地图移动版WM客户端上线
求助：关于铁通宽带的路由器问题 - 电脑数码大卖场 - 淄博旮旯论坛 淄博论坛|淄博信息港...
高级版番茄菜花
铁通之痛
快铁通达都江堰
铁通之痛
沪杭高铁通车运营
王志东进军即时通讯 Lava-Lava部落版上线
丁磊督战163邮箱iPad版上线
百度有啊生活平台低调内测 预计10月正式上线
是谁毁掉了铁通，也毁掉铁通的八万子弟
是谁毁掉了铁通，也毁掉铁通的八万子弟?
大将军高级版全部公式
短线是银高级版