初试锋芒
从一道面试题开始说起
小试牛刀: 一个简单的应用案例
Execl文件的保存过程
你一定会喜欢的技巧
<1>. 抓包:
- 只抓包头
- 只抓必要的包
<2>. 个性化设置:
- 调整时间格式
- 不同类型的网络包可以自定义颜色
- Edit-Preferences更多设置
- 可设置时区与服务器一致
<3>. 过滤:
- 用协议名称过滤
- IP地址+Port号
- 用鼠标帮助过滤
- 可以把过滤后得到的网络包存在一个新的文件里,小文件更方便操作
<4>. 让Wireshark自动分析
- Analyze->Export Info Composite
- Statistics->Service Response Time
- Statistics->TCP Stream Graph
- Statistics->Summary
<5>. Ctrl + F
Patrick的故事
从此我就喜欢上了Wireshark,因为它实在很有用,就像学武之人得到了一把趁手好剑
Wireshark的故事
当你透过它看到网络时，不再是没有意义的0和1，而是可以理解的简洁文字。有了它的专业解说，我们几乎能直接看懂网络上发生的一切。以前难以排查的问题，在它介入后便显露无遗。它还提供了权威的分析报告，比如重传率统计、响应时间和对话列表等，这解放了原本负担繁重的网络管理员，使他们有更多时间专注其他事务。
Gerald把这个软件命名为Ethereal，正对应了它的功能---还原以太网的真相
ethereal 英\[iˈθɪəriəl\] 美\[iˈθɪriəl\] adj. 优雅的; 轻飘的; 缥缈的; 超凡的; \[例句\]She's the prettiest, most ethereal romantic heroine in the movies. 她是所有电影中最美丽、最飘逸的爱情女主角。
庖丁解牛
NFS协议的解析
20世纪80年代初，一家神奇的公司在硅谷诞生了，它就是Sun Microsystems。这个名字与太阳无关，而是源自互联网的伊甸园
----Stanford University Network的首字母。在不到30年的时间里， SUN公司创造了无数传世作品。其中， Java.Solaris和基于SPARC的服务器至今还闻名遐迩。后来，人们总结SUN公司衰落的原因时，有一条竟然是技术过剩。
Network File System （NFS）协议也是SUN公司设计的。顾名思义， NFS就是网络上的文件系统。
portmap的功能是维护一张进程与端口号的对应关系表,而它自己的端口号11是众所周知的
rpcinfo命令
telnet命令
从Wireshark看网络分层
传输层: 虽然名曰”传输层”,但它并不是把网络包从一个设备传到另一个,而只是对传输行为进行控制. 真正负责设备间传输的是下面两层(即网络层和数据链路层)
分工(分层)会带来很多好处,因为每个人都可以专注自己擅长的领域,更好的服务他人.
网络对包的大小是有限制的,其最大值称为MTU,即”最大传输单元”.
知道自己的MTU容易,但对方的MTU如何获得? 在TCP建立连接(三次握手)时,双方都会把自己的MSS(Maxinum Segment Size)告诉对方. MSS加上TCP头和IP头的长度,就得到MTU了.
如MSS是8960,那MTU就是
8960+20(TCP头)+20(IP头)=90008960+20(TCP头)+20(IP头)=9000
.
如果MSS是1460,那MTU就是
1460+20(TCP头)+20(IP头)=15001460+20(TCP头)+20(IP头)=1500
.
发包的大小是由MTU较小的一方决定的
TCP的连接启蒙
nslookup命令
为什么要用三个包来建立连接呢，用两个不可以吗？其实也是可以的，但不够可靠。我们可以设想一个情况来说明这个问题：某个网络有多条路径，客户端请求建立连接的第一个包跑到一条延迟严重的路径上了，所以迟迟没有到达服务器。因此，客户端只能当作这个请求丢失了,不得不再请求一次。由于第二个请求走了正确的路径，所以很快完成工作并关闭了连接。对于客户端来说，事情似乎已经结束了。没想到它的第一个请求经过跋山涉水，还是到达了服务器。服务器并不知道这是一个旧的无效请求，所以按照惯例回复了。假如TCP只要求两次握手，服务器上就这样建立了一个无效连接。而在三次握手的机制下，客户端收到服务器的回复时，知道这个连接不是它想要的，所以就发了一个拒绝包.服务器收到这个包后,也放弃这个连接.
其实用四次挥手来断开连接也不完全可靠,但世界上不存在100%可靠的通信机制.
两军问题与拜占庭将军问题
快递员的工作策略 ---- TCP窗口
TCP显然不用电瓶车送包，但它也有“往返”的需要。因为发包之后并不知道对方能否收到，要一直等到确认包到达，这样就花费了一个往返时间。假如每发一个包就停下来等确认，一个往返时间里就只能传一个包，这样的传输效率太低了。最快的方式应该是一口气把所有包发出去，然后一起确认。但现实中也存在一些限制：接收方的缓存（接收窗口）可能一下子接受不了这么多数据；网络的带宽也不一定足够大，一口气发太多会导致丢包事故。所以，发送方要知道接收方的接收窗口和网络这两个限制因素中哪一个更严格，然后在其限制范围内尽可能多发包。这个一口气能发送的数据量就是传说中的TCP发送窗口。
发送窗口对性能的影响有多大？在相同的往返时间里，右边比左边多发了两倍的数据量。而在真实环境中，发送窗口常常可以达到数十个MSS.
<1>. (如图)每个包的TCP层都含有”windows size:”(也就是win=)的信息. 这个值表示发送窗口的大小吗?
很多人会把接收窗口误认为发送窗口. Windows Size其实不是发送窗口,而是在向对方声明自己的接收窗口.
滑动窗口机制,说的就是这两个窗口的关系
<2>. 我如何在包里看出发送窗口的大小呢?
很遗憾,没有简单办法,有时候甚至完全没有办法.
<3>. 发送窗口和MSS有什么关系?
<4> .发送方在一个窗口里发出n个包,是不是就能收到n个确认包?
<5>. 经常听说”TCP Window Scale”这个概念,它究竟和接收窗口有和关系?
重传的讲究
前文说到,发送方的发送窗口是受接收方的接收窗口和网络影响的,其中限制得更严的因素就起决定作用. 接收窗口的影响方式非常简单,只要在包里用”Win=”告知发送方就可以了. 而网络的影响方式非常复杂,这篇来专门介绍.
能导致网络拥塞的数据量称为拥塞点
慢启动过程
拥塞避免
超时重传
RTO
重复确认(Dup Ack)
快速重传
快速恢复
NewReno
“本文的信息量有点大，你也许需要一些时间来消化它。有些部分一时理解不了也无妨，即便只记住本文导出的几个结论，在工作中也是很有用的:”
- 没有拥塞时，发送窗口越大，性能越好。所以在带宽没有限制的条件下，应该尽量增大接收窗口，比如启用Scale Option （Windows上可参考KB224829）.
- 如果经常发生拥塞，那限制发送窗口反而能提高性能，因为即便万分之一的重传对性能的影响都很大。在很多操作系统上可以通过限制接收窗口的方法来减小发送窗口， Windows上同样可以参考KB 224829
- 超时重传对性能影响最大，因为它有一段时间（RTO）没有传输任何数据,而且拥塞窗口会被设成1个MSS，所以要尽量避免超时重传。
- 快速重传对性能影响小一些，因为它没有等待时间，而且拥塞窗口减小的幅度没那么大。
- SACK和NewReno有利于提高重传效率，提高传输性能。
- 丢包对极小文件的影响比大文件严重。因为读写一个小文件需要的包数很少，所以丢包时往往凑不满3个Dup Ack，只能等待超时重传了。而大文件有较大可能触发快速重传。下面的实验显示了同样的丢包率对大小文件的不同影响：图11中的test是包含很多小文件的目录，而图12的hi是一个大文件。发生丢包时前者耗时增加了7倍多，而后者只增加了不到4倍。
