61.htm

unix高级编程原吗

            再来寻夹岸的桃花。然而，我不敢说来生，也不敢信来生...... <br>
※ 来源:·UNIX编程 www.tiaozhan.com/unixbbs/·[FROM: 211.167.65.123] 发信人: scz <br>
 (小四), 信区: UNP <br>
标  题: Re: unp第五章学习体会 <br>
发信站: UNIX编程 (2001年08月20日09:54:07 星期一), 站内信件 <br>
  <br>
你说的对 <br>
  <br>
clown说对端发送了FIN，己端没有发送FIN <br>
那就不知道他那里测试环境如何了。 <br>
  <br>
  <br>
按道理此时己端是该发送ACK、FIN的 <br>
  <br>
【 在 flyriver (飞流直下) 的大作中提到: 】 <br>
: RST, FIN 都是由内核进行处理的，应用层的进程是接收不到的。 <br>
: 半关闭应该是 shutdown() 来进行的，close() 是不会进行半关闭的。 <br>
: 好久没有看 UNP 了，有些已经忘了。:( <br>
: 【 在 clown (梧桐叶) 的大作中提到: 】 <br>
: :     我kill调子进程以后，服务器确实会发送FIN，但是客户没有发送FIN，因此 <br>
: : .................（以下省略） <br>
  <br>
  <br>
-- <br>
  <br>
            也许有一天，他再从海上蓬蓬的雨点中升起， <br>
            飞向西来，再形成一道江流，再冲倒两旁的石壁， <br>
            再来寻夹岸的桃花。然而，我不敢说来生，也不敢信来生...... <br>
※ 来源:·UNIX编程 www.tiaozhan.com/unixbbs/·[FROM: 211.167.65.123] 发信人: clo <br>
wn (梧桐叶), 信区: UNP <br>
标  题: Re: unp第五章学习体会 <br>
发信站: UNIX编程 (2001年08月20日09:59:34 星期一), 站内信件 <br>
  <br>
中午的时候我再试一下。 <br>

【 在 scz (小四) 的大作中提到: 】 <br>
: 【 在 flyriver (飞流直下) 的大作中提到: 】 <br>
: :                                                   ~~~~~~~~~~~~~~~~~~~~~~~~~~ <br>
: :   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ <br>
: :       不应该这样做吧，你把另一端的进程 kill 掉了，他会用 close() 来关掉 <br>
: :       socket 的，于是内核会完成正常的 TCP 关闭过程。 <br>
: :       应该拔去另一端机器的网线，重启机器，把网线插上去。然后本地进程 <br>
: :       向 socket 写数据时内核就会收到 RST 包了。 <br>
: 我也和flyriver一个观点。kill对端进程会导致TCP连接的正常关闭，close() <br>
: 他的这个拔掉网线的建议还差不多 <br>
-- <br>
※ 来源:·UNIX编程 www.tiaozhan.com/unixbbs/·[FROM: 202.114.1.61] 发信人: clown <br>
 (梧桐叶), 信区: UNP <br>
标  题: Re: unp第五章学习体会 <br>
发信站: UNIX编程 (2001年08月20日20:22:49 星期一), 站内信件 <br>
  <br>
我测试了一下，kill掉服务器端的子进程以后，连接确实是处于半关闭状态！ <br>
测试环境：客户端Linux7.1, 服务器端Linux5.2 <br>
下面是我用tcpdump抓到的报文，服务器->192.168.1.1，客户->192.168.1.69 <br>
服务器端口为8000，我在客户端捕捉数据。 <br>
19:28:50.730295 eth0 > 192.168.1.69.1068 > 192.168.1.1.8000: S 994280979:994 <br>
280979(0) win 5840 <mss 1460,sackOK,timestamp 1222971 0,nop,wscale 0> (DF) <br>

19:28:50.750295 eth0 < 192.168.1.1.8000 > 192.168.1.69.1068: S 2008829808:20 <br>
08829808(0) ack 994280980 win 32120 <mss 1460,sackOK,timestamp 3967913 12229 <br>
71,nop,wscale 0> (DF) <br>
19:28:50.750295 eth0 > 192.168.1.69.1068 > 192.168.1.1.8000: . 1:1(0) ack 1 <br>
win 5840 <nop,nop,timestamp 1222973 3967913> (DF) <br>
上面三个报文说明连接建立。 <br>
19:28:50.750295 eth0 < 192.168.1.1 > 192.168.1.69: icmp: redirect dns.whnet. <br>
edu.cn to host 192.168.2.254 [tos 0xc0] <br>
19:28:55.740295 eth0 < 192.168.1.1 > 192.168.1.69: icmp: redirect dns.whnet. <br>
edu.cn to host 192.168.2.254 [tos 0xc0] <br>
  <br>
19:28:56.450295 eth0 > 192.168.1.69.1068 > 192.168.1.1.8000: P 1:6(5) ack 1 <br>
win 5840 <nop,nop,timestamp 1223543 3967913> (DF) <br>
19:28:56.450295 eth0 < 192.168.1.1.8000 > 192.168.1.69.1068: . 1:1(0) ack 6 <br>
win 32120 <nop,nop,timestamp 3968483 1223543> (DF) <br>
19:28:56.450295 eth0 < 192.168.1.1.8000 > 192.168.1.69.1068: P 1:6(5) ack 6 <br>
win 32120 <nop,nop,timestamp 3968483 1223543> (DF) <br>
19:28:56.450295 eth0 > 192.168.1.69.1068 > 192.168.1.1.8000: . 6:6(0) ack 6 <br>
win 5840 <nop,nop,timestamp 1223543 3968483> (DF) <br>
上面是数据传输，此时kill掉服务器中的子进程 <br>
19:29:39.250295 eth0 < 192.168.1.1.8000 > 192.168.1.69.1068: F 6:6(0) ack 6 <br>
win 32120 <nop,nop,timestamp 3972763 1223543> (DF) <br>

19:29:39.290295 eth0 > 192.168.1.69.1068 > 192.168.1.1.8000: . 6:6(0) ack 7 <br>
win 5840 <nop,nop,timestamp 1227827 3972763> (DF) <br>
服务器发送FIN，客户回应ACK，连接处于半关闭状态。 <br>
19:29:49.710295 eth0 > 192.168.1.69.1068 > 192.168.1.1.8000: P 6:12(6) ack 7 <br>
 win 5840 <nop,nop,timestamp 1228869 3972763> (DF) <br>
客户继续向服务器发送数据，但是接着recv出错，程序返回，因此下面 <br>
会发送FIN。 <br>
19:29:49.710295 eth0 > 192.168.1.69.1068 > 192.168.1.1.8000: F 12:12(0) ack <br>
7 win 5840 <nop,nop,timestamp 1228869 3972763> (DF) <br>
19:29:49.720295 eth0 < 192.168.1.1.8000 > 192.168.1.69.1068: R 2008829815:20 <br>
08829815(0) win 0 <br>
19:29:49.720295 eth0 < 192.168.1.1.8000 > 192.168.1.69.1068: R 2008829815:20 <br>
08829815(0) win 0 <br>
我分析捕捉到的数据的时候，关于序列号的问题突然糊涂了： <br>
           SYN,SEQ=x <br>
      客户----------------->服务器 <br>
           SYN,SEQ=y; ACK=x+1 <br>
         <------------------ <br>
           ACK=y+1 <br>
          ------------------> <br>
SYN包中数据字节数为0，但是ACK中回应下次应接收x+1。在实际的数据 <br>
传输中，如果序列号为z，数据的字节数为0，则对方下次期望收到的数据 <br>

将是z，而不是z+1。这与SYN和ACK数据包是不一样。 <br>
  <br>
  <br>
【 在 scz (小四) 的大作中提到: 】 <br>
: 你说的对 <br>
: clown说对端发送了FIN，己端没有发送FIN <br>
: 那就不知道他那里测试环境如何了。 <br>
: 按道理此时己端是该发送ACK、FIN的 <br>
: 【 在 flyriver (飞流直下) 的大作中提到: 】 <br>
: : RST, FIN 都是由内核进行处理的，应用层的进程是接收不到的。 <br>
: : 半关闭应该是 shutdown() 来进行的，close() 是不会进行半关闭的。 <br>
: : 好久没有看 UNP 了，有些已经忘了。:( <br>
-- <br>
※ 来源:·UNIX编程 www.tiaozhan.com/unixbbs/·[FROM: 202.114.1.61] 发信人: ysqcn <br>
 (岁月无声), 信区: UNP <br>
标  题: Re: unp第五章学习体会 <br>
发信站: UNIX编程 (2001年08月20日21:23:03 星期一), 站内信件 <br>
  <br>
: 我分析捕捉到的数据的时候，关于序列号的问题突然糊涂了： <br>
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^你到底糊涂什么？ <br>
                                           下面的序列号很正常啊 <br>
:            SYN,SEQ=x <br>

:       客户----------------->服务器 <br>
:            SYN,SEQ=y; ACK=x+1 <br>
:          <------------------ <br>
:            ACK=y+1 <br>
:           ------------------> <br>
: SYN包中数据字节数为0，但是ACK中回应下次应接收x+1。在实际的数据 <br>
: 传输中，如果序列号为z，数据的字节数为0，则对方下次期望收到的数据 <br>
: 将是z，而不是z+1。这与SYN和ACK数据包是不一样。 <br>
: <br>
: <br>
: 【 在 scz (小四) 的大作中提到: 】 <br>
: : 你说的对 <br>
: : clown说对端发送了FIN，己端没有发送FIN <br>
: : 那就不知道他那里测试环境如何了。 <br>
: : 按道理此时己端是该发送ACK、FIN的 <br>
: : 【 在 flyriver (飞流直下) 的大作中提到: 】 <br>
: : : RST, FIN 都是由内核进行处理的，应用层的进程是接收不到的。 <br>
: : : 半关闭应该是 shutdown() 来进行的，close() 是不会进行半关闭的。 <br>
: : : 好久没有看 UNP 了，有些已经忘了。:( <br>
: -- <br>
: ※ 来源:·UNIX编程 www.tiaozhan.com/unixbbs/·[FROM: 202.114.1.61] <br>
  <br>
  <br>
-- <br>
一万年太久，只争朝夕... <br>
发信人: clown (梧桐叶), 信区: UNP <br>
标  题: Re: unp第五章学习体会 <br>
发信站: UNIX编程 (2001年08月20日21:25:13 星期一), 站内信件 <br>
  <br>
我糊涂的就时数据部分为0的时候什么时候序列号要加1呀。 <br>
以前以为都要加1的，也就是与SYn包相同。 <br>
我在文中说的是正确的情况。 <br>
【 在 ysqcn (岁月无声) 的大作中提到: 】 <br>
: : 我分析捕捉到的数据的时候，关于序列号的问题突然糊涂了： <br>
: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^你到底糊涂什么？ <br>
:                                            下面的序列号很正常啊 <br>
: :            SYN,SEQ=x <br>
: :       客户----------------->服务器 <br>
: :            SYN,SEQ=y; ACK=x+1 <br>
: :          <------------------ <br>
: :            ACK=y+1 <br>
: :           ------------------> <br>
: : SYN包中数据字节数为0，但是ACK中回应下次应接收x+1。在实际的数据 <br>
: .................（以下省略） <br>
-- <br>
-- <br>
※ 来源:·UNIX编程 www.tiaozhan.com/unixbbs/·[FROM: 202.114.1.61] 发信人: ysqcn <br>
 (岁月无声), 信区: UNP <br>
标  题: Re: unp第五章学习体会 <br>
发信站: UNIX编程 (2001年08月20日21:27:03 星期一), 站内信件 <br>
  <br>
syn与fin占一个字节的序列号，其它的数据为零的不占序号空间 <br>
【 在 clown (梧桐叶) 的大作中提到: 】 <br>
: 我糊涂的就时数据部分为0的时候什么时候序列号要加1呀。 <br>
: 以前以为都要加1的，也就是与SYn包相同。 <br>
: 我在文中说的是正确的情况。 <br>
: 【 在 ysqcn (岁月无声) 的大作中提到: 】 <br>
: : ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^你到底糊涂什么？ <br>
: :                                            下面的序列号很正常啊 <br>
: : .................（以下省略） <br>
  <br>
  <br>
-- <br>
一万年太久，只争朝夕... <br>
※ 来源:·UNIX编程 www.tiaozhan.com/unixbbs/·[FROM: 202.114.2.11] 发信人: clown <br>
 (梧桐叶), 信区: UNP <br>
标  题: Re: unp第五章学习体会 <br>
发信站: UNIX编程 (2001年08月20日21:32:06 星期一), 站内信件 <br>

  <br>
syn和fin为什么要占用一个字节的序列号？他们不是属于tcp首部的 <br>
内容吗？ <br>
正是不明白为什么三次握手中序列号是这样规定的。 <br>
【 在 ysqcn (岁月无声) 的大作中提到: 】 <br>
: syn与fin占一个字节的序列号，其它的数据为零的不占序号空间 <br>
: 【 在 clown (梧桐叶) 的大作中提到: 】 <br>
: : 我糊涂的就时数据部分为0的时候什么时候序列号要加1呀。 <br>
: : 以前以为都要加1的，也就是与SYn包相同。 <br>
: : 我在文中说的是正确的情况。 <br>
-- <br>
※ 来源:·UNIX编程 www.tiaozhan.com/unixbbs/·[FROM: 202.114.1.61] 发信人: ysqcn <br>
 (岁月无声), 信区: UNP <br>
标  题: Re: unp第五章学习体会 <br>
发信站: UNIX编程 (2001年08月20日21:39:53 星期一), 站内信件 <br>
  <br>
相信这个肯定是有缘故的，或者是过去的惯例 <br>
tcp/ip详解没有详细的解释，只是说了一下 <br>
  <br>
【 在 clown (梧桐叶) 的大作中提到: 】 <br>
: syn和fin为什么要占用一个字节的序列号？他们不是属于tcp首部的 <br>
: 内容吗？ <br>

: 正是不明白为什么三次握手中序列号是这样规定的。 <br>
: 【 在 ysqcn (岁月无声) 的大作中提到: 】 <br>
: : syn与fin占一个字节的序列号，其它的数据为零的不占序号空间 <br>
  <br>
  <br>
-- <br>
一万年太久，只争朝夕... <br>
※ 来源:·UNIX编程 www.tiaozhan.com/unixbbs/·[FROM: 202.114.2.11] <br>
</small><hr>
<p align="center">[<a href="index.htm">回到开始</a>][<a href="54.htm">上一层</a>][<a href="62.htm">下一篇</a>]
<p align="center"><a href="http://cterm.163.net">欢迎访问Cterm主页</a></p>
</table>
</body>
</html>