IP网段分类说明
http://zhidao.baidu.com/question/53117368.html
A类：第一个字节第一位必须是0 即0 ****** ，范围00000000~01111111 即0~127
B类：第一个必是1第二位必是0 即10******，范围10000000~10111111 即128~191
c类：前两个必是1第三个必是0 即110*****，范围11000000~11011111 即192~223
A类..1.0.0.1 到 126.255.255.254
B类..128.0.0.1 到 191.255.255.254
C类..192.0.0.1 到 223.255.255.254
D类..224.0.0.1 到239.255.255.254 组播地址
E类..240.0.0.1 到254.255.255.254 仅做研究用
获取外网ip / 如何获取你的外网IP
http://fw.qq.com/ipaddress
http://crane-ding.iteye.com/blog/1251132
<html>
<head>
<title>demo</title>
<meta http-equiv="content-type" content="text/html; charset=utf-8"/>
<script type="text/javascript" src="http://fw.qq.com/ipaddress" charset="GBK"></script>
<script type="text/javascript">
document.write("IP地址:" + IPData[0] + "</br>");
document.write("所在省:" + IPData[2] + "</br>");
document.write("所在市:" + IPData[3] + "</br>");
</script>
</head>
<body></body>
</html>
获取IP地址的方法
http://dpool.sina.com.cn/
Generated Thu, 13 Dec 2012 03:29:01 GMT by xa66-58.sina.com.cn (squid/2.7.STABLE9)
http://int.dpool.sina.com.cn/
http://int.dpool.sina.com.cn/iplookup/
http://int.dpool.sina.com.cn/iplookup/iplookup.php
1 221.226.4.99 221.226.49.255 中国 江苏 南京 电信
http://int.dpool.sina.com.cn/iplookup/iplookup.php?format=js
var remote_ip_info = {"ret":1,"start":"221.226.4.99","end":"221.226.49.255","country":"\u4e2d\u56fd","province":"\u6c5f\u82cf","city":"\u5357\u4eac","district":"","isp":"\u7535\u4fe1","type":"","desc":""};
获取IP的页面js写法
<script type="text/javascript">
function loadSinaJs(delay){
try{
setTimeout(
function(){
var scriptNode = document.getElementsByTagName('script').item(0);
var sina = document.createElement('script');
sina.type = 'text/javascript';
sina.language="javascript";
sina.async = true;
sina.charset = "utf-8";
sina.src="http://int.dpool.sina.com.cn/iplookup/iplookup.php?format=js";
scriptNode.parentNode.insertBefore(sina, scriptNode);
}, delay);
}catch(e){}
}
//延迟加载新浪的获取ip的api js
loadSinaJs(500);
function getCityName(){
var cityName= remote_ip_info.city;
cityName = encodeURI(encodeURI(cityName));
url="/vgs-web/weather/index.htm?cityName="+cityName;
window.open(url, "_blank");
}
</script>
TCP/IP 当前并发连接数查看
Windows 7 x64 中文版
C:\Users\Administrator>netstat -s | findstr 当前连接
当前连接 = 12 （IPv4）
当前连接 = 0 （IPv6）
Windows Server 2003 SP2 x64 en
C:\Documents and Settings\Administrator>netstat -s | findstr Current
Current Connections = 120
TCP/IP连接数破解真的有用吗？
http://wenku.baidu.com/view/682ffcafdd3383c4bb4cd24a.html###
Intelligent TCPIP.SYS patcher / EventID 4226 patch Version 2.23d
http://www.lvllord.de/download.php?url=en/EvID4226Patch223d-en.zip
http://dl.iteye.com/topics/download/c1ebba78-7d9c-3ed2-bb41-1191684bbb72
(c) 2004-05 LvlLord (www.LvlLord.de) use parameter /? for more options
This program is in development. Visit http://www.LvlLord.de for a new version
--------------------------------------------------------------------------------
- Windows mode
- Recognised Windows-directory: C:\Windows
C:\Windows\System32\Drivers\TCPIP.SYS cannot be accessed.
Try using 64-bit system file unlock ...
Unlocking 64-bit system files ...
Retrying accessing file ...
Error:
========
Error read file "C:\Windows\System32\Drivers\TCPIP.SYS" at position 0.
Press any key to exit ...
http://bbs.kafan.cn/thread-479329-1-1.html
正确的说法是：XP SP2只允许同时存在10个TCP半开连接。
1、什么是TCP半开连接？ （并发连接）
所谓半开TCP连接，简单地说就是发送了TCP连接请求，但还没有得到对方应答的状态（实际上要复杂些），也就是连接尚未完全建立起来，双方还无法进行通信交互的状态。
TCP当前并发连接数查看方法
IPv4 的 TCP 统计信息
主动开放 = 53052
被动开放 = 3577
失败的连接尝试 = 13033
重置连接 = 6699
当前连接 = 7
接收的分段 = 4326185
发送的分段 = 3659708
重新传输的分段 = 24309
2、XP限制了TCP连接数量吗？
XP SP2没有限制TCP连接数量。
3、半开连接数量限制对上传、下载速率有什么影响吗？
几乎没有影响。
半开连接数限制充其量仅会在连接时引入一点时延（从几毫秒到几百毫秒）而已。而数据交互是在已经建立的TCP连接上传输的，传输速率与半开连接数量无关。更何况P2P协议本身还有排队、请求数据等，这些机制引入的时延都远远大于半开连接限制所带来的时延（例如，你连接了数百个对端，但是传输数据的却只有其中的几十个而已，其中大部分都处于等待或闲置状态）。因此，半开连接数限制对上传、下载速率几乎没有影响。
4、TCP半开连接数量设置为多少比较合适？
不超过50为宜。没有必要设置得太大。
因为每一个半开连接都会系统（包括路由器、防火墙、操作系统等）引入额外的开销，过多的半开连接数只会导致系统资源紧张、不稳定甚至崩溃，却不能带来传输速率在实质上的提高。例如，在P2P网络中，一个黑客可以通过散布虚假资源信息，引导大量客户端在短时间内试图与某个被攻击者建立连接，如果半开连接数设置过大，将导致系统崩溃（路由器梗死、防火墙瘫痪或者操作系统崩溃等）。还有其它很多DDoS攻击手段。限制TCP半开连接数，可以有效地防止DDoS攻击。
5、如何知道当前的传输速率？
用任务管理器的网络选项卡或者防火墙查看网卡实际传输了多少数据才是最准确的，下载软件显示的值有可能是虚假的。
最后，希望大家不要迷信TCP半开连接数量会明显提高传输速率的谣言。
实际传输速率=同时连接的数量×有效连接（源）占的比例x对端上传通道平均上传速率x平均传输时间÷连接持续时间。
其次，你所举出的论据是因为各种BT软件都会有破解TCP/IP连接数，无论国内还国外的。这是一种侧面的推论
那我且问一个“谁是因 谁是果”
如果我开发一个BT软件给你，你肯定第一句就说我连“破解TCP/IP的功能都没有”。
若我作为开发者，是集成这个功能给你呢(反正很简单，自动手动都可以)？还是打死不从呢？
6、典型的例子就是 组策略里修改QOS保留带宽
破解半开连接数的作用是让你在下载时还可以浏览网页。
比如微软前阵子先后发过2个补丁打上重启后BT下载时打不开网页就是因为把连接数改回了10
HTTP浏览器并发连接数
http://blog.csdn.net/phphot/article/details/3210221
作者：老王
这是个老话题了，先总结一下HTTP1.1下主流浏览器在单个主机下的并发连接数：
IE7 2
IE8 6
Firefox2 2
Firefox3 6
看上去巧合的是：老版本的IE和Firefox都使用较低的单个主机并发连接数（2），而新版本的IE和Firefox都使用较高的单个主机并发连接数（6）。说起来老版本的IE和Firefox之所以采用较低的单个主机并发连接数是有道理的，在RFC2616 里明确要求了单个主机并发连接数的数目：
Clients that use persistent connections SHOULD limit the number of simultaneous connections that they maintain to a given server. A single-user client SHOULD NOT maintain more than 2 connections with any server or proxy. A proxy SHOULD use up to 2*N connections to another server or proxy, where N is the number of simultaneously active users. These guidelines are intended to improve HTTP response times and avoid congestion.
不过标准总会落后于现实。在当今的网络环境里再使用较低的单个主机并发连接数已经越来越显得不合时宜了，所以说新版本的IE和Firefox才会不约而同的采用较高的单个主机并发连接数。
不 过很多时候我们为了效率还想得到更高的并发连接数，比如说我们总会看到一些大网站采用独立域名或者二级域名来设置专门的图片服务器，其实有一部分原因就是 为了增加并发连接数。至于使用独立域名还是二级域名的差别在于Cookie的影响，当使用和主站根域名相同的二级域名时，请求的同时也会捎带着传递主站根 域名的Cookie，而使用和主站根域名不同的独立域名时，则不会受主站根域名Cookie的影响，所以带宽占用会更小一些。
不过也不是说并发连接数越大越好，假如新版浏览器得到普及，即使你的网站的平均流量还维持在和以前一样的水平，那么峰值流量也会成倍增加。
顺便说说Firefox下怎么调整单个主机下的并发数：
# about:config
network.http.max-connections : 30
network.http.max-connections-per-server : 15
network.http.max-persistent-connections-per-proxy : 8
network.http.max-persistent-connections-per-server: 6
需 要说明的是HTTP1.1下以network.http.max-persistent-connections-per-server的指为准，这是因 为HTTP1.1下缺省都是持久连接，反之如果是HTTP1.0，则以network.http.max-connections-per-server 为准。
如果你使用TamperData检测一下，就能发现：
HTTP1.1下Connection: Keep-Alive
HTTP1.0下Connection: Close
参考链接：Roundup on Parallel Connections
记一次TIME_WAIT网络故障
http://huoding.com/2012/01/19/142
红薯linux和windows下TIME_WAIT过多的解决办法
http://www.oschina.net/question/12_623
如果使用了nginx代理，那么系统TIME_WAIT的数量会变得比较多，这是由于nginx代理使用了短链接的方式和后端交互的原因，使得nginx 和后端的ESTABLISHED变得很少而TIME_WAIT很多。这不但发生在安装nginx的代理服务器上，而且也会使后端的app服务器上有大量的 TIME_WAIT。查阅TIME_WAIT资料，发现这个状态很多也没什么大问题，但可能因为它占用了系统过多的端口，导致后续的请求无法获取端口而造 成障碍。虽然TIME_WAIT会造成一些问题，但是要完全枪毙掉它也是不正当的，虽然看起来这么做没什么错。具体可看这篇文档：
http://hi.baidu.com/tim_bi/blog/item/35b005d784ca91d5a044df1d.html
所以目前看来最好的办法是让每个TIME_WAIT早点过期。
在linux上可以这么配置：
#让TIME_WAIT状态可以重用，这样即使TIME_WAIT占满了所有端口，也不会拒绝新的请求造成障碍
echo "1" > /proc/sys/net/ipv4/tcp_tw_reuse
#让TIME_WAIT尽快回收，我也不知是多久，观察大概是一秒钟
echo "1" > /proc/sys/net/ipv4/tcp_tw_recycle
很多文档都会建议两个参数都配置上，但是我发现只用修改tcp_tw_recycle就可以解决问题的了，TIME_WAIT重用TCP协议本身就是不建议打开的。
不能重用端口可能会造成系统的某些服务无法启动，比如要重启一个系统监控的软件，它用了40000端口，而这个端口在软件重启过程中刚好被使用了，就可能会重启失败的。linux默认考虑到了这个问题，有这么个设定：
#查看系统本地可用端口极限值
cat /proc/sys/net/ipv4/ip_local_port_range
用这条命令会返回两个数字，默认是：32768 61000，说明这台机器本地能向外连接61000-32768=28232个连接，注意是本地向外连接，不是这台机器的所有连接，不会影响这台机器的 80端口的对外连接数。但这个数字会影响到代理服务器（nginx）对app服务器的最大连接数，因为nginx对app是用的异步传输，所以这个环节的 连接速度很快，所以堆积的连接就很少。假如nginx对app服务器之间的带宽出了问题或是app服务器有问题，那么可能使连接堆积起来，这时可以通过设 定nginx的代理超时时间，来使连接尽快释放掉，一般来说极少能用到28232个连接。
因为有软件使用了40000端口监听，常常出错的话，可以通过设定ip_local_port_range的最小值来解决：
echo "40001 61000" > /proc/sys/net/ipv4/ip_local_port_range
但是这么做很显然把系统可用端口数减少了，这时可以把ip_local_port_range的最大值往上调，但是好习惯是使用不超过32768的端口来侦听服务，另外也不必要去修改ip_local_port_range数值成1024 65535之类的，意义不大。
因为使用了nginx代理，在windows下也会造成大量TIME_WAIT，当然windows也可以调整：
在注册表（regedit）的HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters上添加一个DWORD类型的值TcpTimedWaitDelay，值就是秒数，即可。
windows默认是重用TIME_WAIT，我现在还不知道怎么改成不重用的，本地端口也没查到是什么值，但这些都关系不大，都可以按系统默认运作。
可以看看这篇文档：
http://morganchengmo.spaces.live.com/blog/cns!9950CE918939932E!1721.entry
记一次TIME_WAIT网络故障
http://huoding.com/2012/01/19/142
最近发现一个PHP脚本时常出现连不上服务器的现象，调试了一下，发现是TIME_WAIT状态过多造成的，本文简要介绍一下解决问题的过程。
遇到这类问题，我习惯于先用strace命令跟踪了一下看看：
shell> strace php /path/to/file
EADDRNOTAVAIL (Cannot assign requested address)
从字面结果看似乎是网络资源相关问题。这里顺便介绍一点小技巧：在调试的时候一般是从后往前看strace命令的结果，这样更容易找到有价值的信息。
查看一下当前的网络连接情况，结果发现TIME_WAIT数非常大：
shell> netstat -nt | awk '/^tcp/ {++state[$NF]} END {for(key in state) print key,"\t",state[key]}'
TIME_WAIT 28233
重复了几次测试，结果每次出问题的时候，TIME_WAIT都等于28233，这真是一个魔法数字！实际原因很简单，它取决于一个内核参数net.ipv4.ip_local_port_range：
shell> sysctl -a | grep port
net.ipv4.ip_local_port_range = 32768 61000
因为端口范围是一个闭区间，所以实际可用的端口数量是：
shell> echo $((61000-32768+1))
28233
问题分析到这里基本就清晰了，解决方向也明确了，内容所限，这里就不说如何优化程序代码了，只是从系统方面来阐述如何解决问题，无非就是以下两个方面：
首先是增加本地可用端口数量。这点可以用以下命令来实现：
shell> echo "net.ipv4.ip_local_port_range = 10240 61000" >> /etc/sysctl.conf
shell> sysctl -p
其次是减少TIME_WAIT连接状态。网络上已经有不少相关的介绍，大多是建议：
shell> sysctl net.ipv4.tcp_tw_reuse=1
shell> sysctl net.ipv4.tcp_tw_recycle=1
注：通过sysctl命令修改内核参数，重启后会还原，要想持久化可以参考前面的方法。
这两个选项在降低TIME_WAIT数量方面可以说是立竿见影，不过如果你觉得问题已经完美搞定那就错了，实际上这样可能会引入一个更复杂的网络故障。
关于内核参数的详细介绍，可以参考官方文档。我们这里简要说明一下tcp_tw_recycle参数。它用来快速回收TIME_WAIT连接，不过如果在NAT环境下会引发问题。
RFC1323中有如下一段描述：
An additional mechanism could be added to the TCP, a per-host cache of the last timestamp received from any connection. This value could then be used in the PAWS mechanism to reject old duplicate segments from earlier incarnations of the connection, if the timestamp clock can be guaranteed to have ticked at least once since the old connection was open. This would require that the TIME-WAIT delay plus the RTT together must be at least one tick of the sender’s timestamp clock. Such an extension is not part of the proposal of this RFC.
大概意思是说TCP有一种行为，可以缓存每个连接最新的时间戳，后续请求中如果时间戳小于缓存的时间戳，即视为无效，相应的数据包会被丢弃。
Linux是否启用这种行为取决于tcp_timestamps和tcp_tw_recycle，因为tcp_timestamps缺省就是开启的，所以当tcp_tw_recycle被开启后，实际上这种行为就被激活了。
现在很多公司都用LVS做负载均衡，通常是前面一台LVS，后面多台后端服务器，以NAT方式构建，当请求到达LVS后，它修改地址数据后便转发给后端服务器，但不会修改时间戳数据，对于后端服务器来说，请求的源地址就是LVS的地址，加上端口会复用，所以从后端服务器的角度看，原本不同客户端的请求经过LVS的转发，就可能会被认为是同一个连接，加之不同客户端的时间可能不一致，所以就会出现时间戳错乱的现象，于是后面的数据包就被丢弃了，具体的表现通常是是客户端明明发送的SYN，但服务端就是不响应ACK，还可以通过下面命令来确认数据包不断被丢弃的现象：
shell> netstat -s | grep timestamp
... packets rejects in established connections because of timestamp
如果服务器身处NAT环境，安全起见，通常要禁止tcp_tw_recycle，至于TIME_WAIT连接过多的问题，可以通过激活tcp_tw_reuse来缓解。
进一步思考，既然必须同时激活tcp_timestamps和tcp_tw_recycle才会触发这种现象，那只要禁止tcp_timestamps，同时激活tcp_tw_recycle，就可以既避免NAT丢包问题，又降低TIME_WAIT连接数量。如果服务器并不依赖于RFC1323，那么这种方法应该也是可行的，不过最好多做测试，以防有其他的副作用。
shell> sysctl net.ipv4.tcp_timestamps=0
shell> sysctl net.ipv4.tcp_tw_recycle=1
…
总体来说，这次网络故障本身并没什么高深之处，本不想罗罗嗦嗦写这么多，不过拔出萝卜带出泥，在过程中牵扯的方方面面还是值得大家品味的，于是便有了这篇文字。
This entry was posted in Technical and tagged Linux by 老王. Bookmark the permalink.
xiaobai on 2012-06-27 at 12:35:42 said:
老王 on 2012-06-27 at 15:48:48 said:LVS有多种运行方式，其中包括我文中提及的NAT，至于你指出的问题，我会再确认一下，非常感谢你的反馈！
[root@nginxServer4 ~]# netstat -an|awk '/tcp/ {print $6}'|sort|uniq -c
55 ESTABLISHED
5 FIN_WAIT1
31 LISTEN
12 TIME_WAIT
[root@nginxServer4 ~]# netstat -n|awk '/^tcp/{++S[$NF]} END {for(a in S) print a,S[a]}'
TIME_WAIT 13
FIN_WAIT1 1
ESTABLISHED 149
LAST_ACK 1
解析：
CLOSED //无连接是活动的或正在进行
LISTEN //服务器在等待进入呼叫
SYN_RECV //一个连接请求已经到达，等待确认
SYN_SENT //应用已经开始，打开一个连接
ESTABLISHED //正常数据传输状态/当前并发连接数
FIN_WAIT1 //应用说它已经完成
FIN_WAIT2 //另一边已同意释放
ITMED_WAIT //等待所有分组死掉
CLOSING //两边同时尝试关闭
TIME_WAIT //另一边已初始化一个释放
LAST_ACK //等待所有分组死掉
linux shell 定时ping 服务器主机网络状态
[root@b2clogbackup lindows]# more pingall.sh #!/bin/sh #pingall #grab /etc/hosts and ping each address #author:wangzhongqiang # $1表示第一行 # grep -v "^$" 去除删除所有空白行 cat $PWD/yuming.txt |grep -v "^#"|grep -v "^$"|while read LINE do set $LINE for MACHINE in $1 do ping -c 5 $MACHINE done done
[root@b2clogbackup lindows]# more yuming.txt
xiamiwang.net
www.xiamiwang.net
mail.xiamiwang.net
bbs.xiamiwang.net
192.168.100.182
HTTP是基于TCP的还是基于UDP的？-软考/资格水平考试>> 系统分析师
http://bbs.csai.cn/BBSOldArticle/T2/BB68B090-6370-45A0-8249-2B5D29B84B15.html
1.TCP及UDP都有80端口，都是HTTP协议的
2.对于TCP及UDP，IE应都会正常访问
3.一般小的WEB软件可以采用TCP，但对于大型的WEB不可能采用
TCP，肯定是UDP，编过服务器程序的人都应知道，每个TCP连接
都要在服务器端生成一个SOCKET
4.如果采用SSL协议，可能就使用TCP协议了(也可能UDP也支持)
TCP/IP传输层，你懂多少？
http://java-mzd.iteye.com/blog/1007577
1. 传输层的主要功能是什么？
2. 传输层如何区分不同应用程序的数据流？
3. 传输层有哪些协议？
4. 什么是UDP协议？
5. 为什么有了UDP，还需要TCP？
6. 什么是TCP协议？
7. 怎么理解协议和程序？
8. TCP是否真的有链接？
9. 链接是如何建立的（逻辑上）？
10. 所谓的建立TCP链接开销很大，具体是指什么？
11. 三次握手的目的是什么？
12. TCP如何提供可靠性？
13. 什么是预期确认？什么是肯定确认与重新传输？哪些情况会重传？
14. TCP中，序列号和应答号有哪些作用？
15. TCP链接中，网络失败，是怎么判断的？
16. 为什么需要窗口技术？
17. 如何实现流量控制？
18. UDP的开销很小，具体是指什么？
19. UDP数据包、TCP数据包大小如何确认？
20. UDP适合哪些环境？TCP适合哪些环境？
一。传输层的主要功能是什么？
分割 并重新组装 上层提供的数据流，为数据流提供端到端 的传输服务。
二。传输层如何区分不同应用程序的数据流？
因为，对应传输层而言，它只需要知道目标主机上的哪个服务程序来响应这个程序，而不需要知道这个服务程序是干什么的。因此，我们只需要能够抽象的表示出来这些应用程序和服务程序即可。我们使用端口号来抽象标识每个网络程序 。
|
传输层的TCP和UDP可以接收来自多个应用程序的数据流，用端口号标识他们，然后把他们送给Internet层处理； 同时TCP和UDP接收来自Internet层的数据包，用端口号区分他们，然后交给不同的应用程序。 |
因此：在同一IP地址（同一个目标主机）上不同的端口号是两个不同的链接。 IP地址和端口号用来唯一的确定网络上数据的目的地。
三。传输层有哪些协议？
传输层的两大协议：TCP（传输控制协议）UDP（用户数据包协议）
TCP是一个可靠的面向链接的协议，UDP是不可靠的或者说无连接的协议。
可以用打电话和发短信来说明这种关系：
UDP就好似发短信，只管发出去，至于对方是不是空号（网络不可到达）能不能收到（丢包）等并不关心。
TCP好像打电话，双方要通话，首先，要确定对方不是开机（网络可以到达），然后要确定是不是没有信号（），然后还需要对方接听（通信链接）。
四。什么是UDP协议？
UDP数据包结构如下图所示
|
源端口 (16) |
目标端口 (16) |
|
报文长度 (16) |
校验和 (16) |
|
数据（可变） |
UDP为应用程序提供的是一种不可靠的、无连接的分组交付 ，因此，UDP报文可能会出现丢失 、乱序 、重复 、延时 等问题。
| 因为它不提供可靠性，它的开销很小。（开销很小具体指什么？ 下文揭秘） |
五。为什么有了UDP，还需要TCP？
问题4中已经说到，UDP为应用程序提供的是一种无连接、不可靠的分组交付。当网络硬件失效或者负担太重时，数据包可能就会产生丢失、重复、延时、乱序的现象。 这些都会导致我们的通信不正常。如果让应用程序来担负差错控制的工作，无疑将给程序员带来许多复杂的工作，于是，我们使用独立的通信协议来保证通信的可靠性是非常必要的。
六。什么是TCP协议？
传输控制协议TCP是一个面向链接的、可靠的通信协议。
1. 在开始传输前，需要进行三次握手建立链接
2. 可靠性：在传输过程中，通信双方的协议模块继续进行通信
3. 通信结束后，通信双方都会使用改进的三次握手来关闭链接
TCP数据包结构如下图
|
源端口 (16) |
目标端口 (16) |
||
|
序号 (32) |
|||
|
应答号 (32) |
|||
|
头长度 (4) |
保留 (6) |
编码位 (6) |
窗口 (16) |
|
校验和 (16) |
紧急 (16) |
||
|
可选项 ( 如果有， 0 或 32) |
|||
|
数据 ( 可变 ) |
**七。怎么理解协议和程序？**
如同我们自定义的应用层协议一样： 协议只是给出了一组规范，规定我们应该怎么样（按什么规则）保存数据。
在计算机间传输的永远都是二进制字节码（对于传输层，可以理解为传输的始终是下层的IP数据包），是 计算机中的程序通过对这些字节码进行逻辑分析、判断，来控制程序完成差错控制等功能。
至于解析这些字节码的程序，则可以有不同的实现，只要我们按照规则来解析，并作出相应的控制，我们大可以自己写个程序是实现相应功能。
|
知道了这些后，显然，我们也可以使用前面说的Jpcap，来自己实现一个基于Java的TCP或者UDP协议。可以参考Linux下的Tcp源码。 /net/ipv4/udp.c |
八。TCP是否真的有链接？
我们都知道，TCP通过完成三次握手来建立链接的，但是这种连接是面向虚电路的，是物理上不存在的 ， 只是双方的TCP程序，逻辑上的认为建立了这样的链接 。
九。链接是如何建立的（逻辑上）？
假设：当我们在主机 A 上启动一个程序，通过 TCP 去链接主机 B 上的 9091 端口。
整个过程是怎么样的呢？逻辑上我们可以这么理解建立链接的过程：
1.SYN:seq=X;
1.1 A的TCP程序，为这个链接分配一个端口（设为9090）。
1.2 同时逻辑上 的将TCP连接的状态设置为：正在连接。（通过在链接状态表中添加一条记录，记录中状态为：正在连接）
猜想：
|
TCP程序中， 应该有张表来保持链接的状态，其中每个状态应该有： 本机地址（IP加port）、对方地址、链接状态 |
1.3 同时，随机生成一个初始序列号X，生成一个TCP包，将初始化序列号X设置为TCP中的序列号，发送给主机B。
2.SYN:seq=Y ACK:ack=X+1;
2.1 B上TCP程序收到该数据包，查询9091端口状态，如果可以链接。
2.2 同样的，在逻辑上的将TCP连接的状态设置为：正在连接
2.3 同时，随机生成一个初始化序列号Y，根据接收的序列号X，生成应答号X+1，生成一个TCP包，将序列号和应答号分别设置到TCP包头中，将TCP数据包发给主机A。
3.SYN:seq=X+1 ACK:ack=Y+1.
3.1 A上的TCP程序接收到数据包，查询9090端口状态。
3.2 根据收到的SYN:seq=Y;ACK:ack=X+1; 封装一个TCP包 SYN:seq=x+1;ACK:ack=Y+1;发送给主机B。同时，TCP程序将链接状态表中该条记录状态设置为已连接。
3.3 主机B收到数据包，TCP程序将链接状态表中该条记录状态设置为已连接。
至此，一个TCP链接建立（三次握手）完成。
我们可以看到：
第一：传送的都是IP数据包，其实只是将收到的数据包交给TCP程序处理。
第二：链接状态，只是TCP程序中的一个逻辑状态。
十：所谓的建立TCP链接开销很大，具体是指什么？
从九中，很容易看出。要简历TCP链接，必须进行三次IP数据包的成功传输。
十一：三次握手的目的是什么？
TCP是面向链接的，在面向链接的环境中，开始传输数据之前，在两个中端之间必须先建立一个链接。 建立链接的过程可以确保通信双方在发送应用程序数据包之前，都已经准备好了传送和接收数据。 并且使通信双方统一了初始化序列号。
十二：TCP如何提供可靠性？
在传输过程中，通信双方的协议模块继续进行通信，从而确保了传输的可靠性。
针对乱序： 在通过三次握手进行链接时，序列号被初始化。在传输过程中，TCP继续使用这个序列号来标记发送的每一个数据段，没传送一个数据段，序列号加一。接收方依据序列号重装收到的数据段 。
针对丢包 ： 在传输过程中，接收方收到一个数据段后，会用ACK应答码向发送端回复一个IP包进行应答，确认号ACK用来告诉发送端哪些数据包已经成功接收，发送方对未被应答的报文段提供重传 。
针对重复 ： 接收端收到数据段后，查看序列号，如果已经成功接收改数据包，则丢弃后面这个数据段。
针对延时 ： 延时造成的第一个问题，就是数据包达到接收端时乱序。
当延时严重时，接收端一直未收到数据段，则不会回复ACK，发送端认为丢包，重发。
十三：什么是预期确认？什么是肯定确认与重新传输？哪些情况会重传？
1.确认号ACK会告诉发送端哪些数据段已经成功接收，并且确认号会向发送端指出接收端希望收到的下一个序列号。即，确实号ACK为上个数据序列号+1，这种机制称为预期确认 。
2.为了提高效率，我们在发送端，将数据段保存在缓冲区中，直道发送端收到来自接收端的确认号。这种机制被称为“肯定确认与重新传输 ”。
3.当发送端在给定时间间隔内收不到那个数据段的应答时，发送端就会重传那个数据段 。
情况1：网络延时/环路，数据段丢失
情况2：网络延时，数据段推迟到达
情况3：数据段成功到达，应答因为1.2不能达到。
十四： TCP中，序列号和应答号有哪些作用？
从以上10,11,12中，很明显的可以看到
-
-
- 依靠序列号重组数据段
- 依靠数据包消除网络中的重复包
- 依靠序列号和应答号进行差错重传，提高了TCP的可靠性
-
十六：为什么需要窗口技术？
前面我们已经说了，TCP的可靠性，是通过预期确认来实现的。即发送方发送一个数据段后，需要得到对方的确认后，才会发送下一个数据段。
因此，假设一个数据段大小为64KB（IP包最大值），一次发送和确认需要的时间为500MS，则，1S内，只能传送128KB的数据，如果带宽为1M，显然很浪费带宽。为了充分利用带宽，我们使用窗口技术 。 滑动窗口允许发送方在收到接收方的确认之前发送多个数据段 。（窗口大小决定了在收到确认前可以发送的数据段数量）
十七：如何实现流量控制？
窗口数决定了当前传输的最大流量 。当我们在传输过程中，通信双方可以根据网络条件动态协商窗口大小 ，调整窗口大小时，即可实现流量控制。 （在TCP的每个确认中，除了ACK外，还包括一个窗口通知）
十八：UDP的开销很小，具体是指什么？
1.因为UDP是无连接的。在传输数据之前 ，不需要进行复杂的三次握手来建立连接。
2.在传输数据时 ，没有协议间通信流量 （确认信号），也不需要浪费不必要的处理时间（接收确认信号再发一下）。
3；传输结束后 ，也不用再用改进的三次握手来端口连接 。
十九：UDP数据包、TCP数据包大小如何确认？
-
-
无论TCP还是UDP数据包，都需要交给Internet层封装为IP包，而一个IP包，包头中的长度位为16位，所以IP包最大为2的16方，即65535 （64KB还需要减去各种包头长度）。 -
TCP因为面向流，且可以凭借序列号对大文件进行分段和重组，因此，TCP可以用来传输较大的文件 。而UDP，如果要传输大于64KB的数据，则需要自己在应用层进行差错控制 。 -
为了提高传输效率和减少网络通信量（协议间的通信），TCP也会一次传输足够多的数据 。 -
因为MTU的存在，TCP包和UDP包不是越大越好 。（在路由中分包，在接收端重组，加大路由与接收端负担，增大丢包概率。分组丢失，整个数据包重传。）
-
二十：UDP适用哪些环境？TCP适用哪些环境？
适合UDP的环境：
1.在高效可靠的网络 环境中 （不需要考虑网络不好导致的丢包、乱序、延时、重复等问题），因为UDP是无连接的服务，不用消耗不必要的网络资源（TCP中的协议间通信）和处理时间（预期确认需要的时间）， 从而效率要高的多。
2.在轻权通信 中 ，当需要传输的数据量很小（可以装在一个IP数据包内）时。如果我们使用TCP协议，那么，先建立连接，一共需要发送3个IP数据包，然后数据传输，1个IP数据包，产生一个确认信号的IP包，然后关闭连接，需要传输5个IP数据包。使用TCP协议IP包的利用率为1/10 。而使用UDP，只需要发送一个IP数据包。哪怕丢包（服务不成功），也可重新申请服务（重传）。
| 注：而且无论UDP还是TCP，传输的都是IP数据包。当网络环境不好导致丢包时，无论TCP还是UDP都会丢包，这是没有区别的。（如果考虑发送丢包，那么TCP效率更低），只是使用TCP，当连接建立成功后，TCP程序会进行可靠性控制。 |
UDP很适合这种客户机向服务器传送简单服务请求的环境 。此类应用层协议包括TFTP , SNMP , DNS ,DHCP等。
3.在对实时性要求很强 的通信中 ：在诸如实时视频直播等对实时性要求很高的环境中，从而允许一定量的丢包的情况下（直播比赛，前面丢失的包，重传出来已经意义不大了），UDP更适合。（可以根据具体需要通过应用层协议提供可靠性，不用像TCP那么严格。）
适合TCP协议的环境：
当网络硬件失效或者负担太重时，数据包可能就会产生丢失、重复、延时、乱序的现象 。这些都会导致我们的通信不正常的时候 。如果让应用程序来担负差错控制的工作，无疑将给程序员带来许多复杂的工作，于是，我们使用独立的通信协议来保证通信的可靠性是非常必要的。
TCP/UDP 端口
http://www.networkdictionary.net/networking/tcpudp.php
TCP 和 UDP 都是 IP 层的传输协议，是 IP 与上层之间的处理接口。TCP 和 UDP 协议端口号被设计来区分运行在单个设备上的多重应用程序的 IP 地址。
由于同一台机器上可能会运行多个网络应用程序，所以计算机需要确保目标计算机上接收源主机数据包的软件应用程序的正确性，以及响应能够被发送到源主 机的正确应用程序上。该过程正是通过使用TCP 或 UDP 端口号来实现的。在 TCP 和 UDP 头部分，有“源端口”和“目标端口”段，主要用于显示发送和接收过程中的身份识别信息。IP 地址和端口号合在一起被称为“套接字”。
IETF IANA 定义了三种端口组：公认端口（Well Known Ports）、注册端口（RegisteredPorts）以及动态和/或私有端口（Dynamic and/or Private Ports） 。
- 公认端口（Well Known Ports）从0到1023。
- 注册端口（RegisteredPorts）从1024到49151。
- 动态和/或私有端口（Dynamic and/or Private Ports）从49152到65535。
部分TCP/UDP端口
| 端口号 | 协议 | 服务名称 | 别名 | 注释 |
| 7 | TCP | echo | Echo | |
| 7 | UDP | echo | Echo | |
| 9 | TCP | discard | sink null | Discard |
| 9 | UDP | discard | sink null | Discard |
| 13 | TCP | daytime | Daytime | |
| 13 | UDP | daytime | Daytime | |
| 17 | TCP | qotd | quote | Quote of the day |
| 17 | UDP | qotd | quote | Quote of the day |
| 19 | TCP | chargen | ttytst source | Character generator |
| 19 | UDP | chargen | ttytst source | Character generator |
| 20 | TCP | ftp-data | File Transfer | |
| 21 | TCP | ftp | FTP Control | |
| 23 | TCP | telnet | Telnet | |
| 25 | TCP | smtp | Simple Mail Transfer | |
| 37 | TCP | time | Time | |
| 37 | UDP | time | Time | |
| 39 | UDP | rlp | resource | Resource Location Protocol |
| 42 | TCP | nameserver | name | Host Name Server |
| 42 | UDP | nameserver | name | Host Name Server |
| 43 | TCP | nicname | whois | Who Is |
| 53 | TCP | domain | Domain Name | |
| 53 | UDP | domain | Domain Name Server | |
| 67 | UDP | bootps | dhcps | Bootstrap Protocol Server |
| 68 | UDP | bootpc | dhcpc | Bootstrap Protocol Client |
| 69 | UDP | tftp | Trivial File Transfer | |
| 70 | TCP | gopher | Gopher | |
| 79 | TCP | finger | Finger | |
| 80 | TCP | http | www，http | World Wide Web |
| 88 | TCP | kerberos | krb5 | Kerberos |
| 88 | UDP | kerberos | krb5 | Kerberos |
| 101 | TCP | hostname | hostnames | NIC Host Name Server |
| 102 | TCP | iso-tsap | ISO-TSAP Class 0 | |
| 107 | TCP | rtelnet | Remote Telnet Service | |
| 109 | TCP | pop2 | postoffice | Post Office Protocol - Version 2 |
| 110 | TCP | pop3 | postoffice | Post Office Protocol - Version 3 |
| 111 | TCP | sunrpc | rpcbind portmap | SUN Remote Procedure Call |
| 111 | UDP | sunrpc | rpcbind portmap | SUN Remote Procedure Call |
| 113 | TCP | auth | ident tap | Authentication Sevice |
| 117 | TCP | uucp-path | UUCP Path Service | |
| 119 | TCP | nntp | usenet | Network News Transfer Protocol |
| 123 | UDP | ntp | Network Time Protocol | |
| 135 | TCP | epmap | loc-srv | DCE endpoint resolution |
| 135 | UDP | epmap | loc-srv | DCE endpoint resolution |
| 137 | TCP | netbios-ns | nbname | NETBIOS Name Service |
| 137 | UDP | netbios-ns | nbname | NETBIOS Name Service |
| 138 | UDP | netbios-dgm | nbdatagram | NETBIOS Datagram Service |
| 139 | TCP | netbios-ssn | nbsession | NETBIOS Session Service |
| 143 | TCP | imap | imap4 | Internet Message Access Protocol |
| 158 | TCP | pcmail-srv | repository | PC Mail Server |
| 161 | UDP | snmp | snmp | SNMP |
| 162 | UDP | snmptrap | snmp-trap | SNMP TRAP |
| 170 | TCP | print-srv | Network PostScript | |
| 179 | TCP | bgp | Border Gateway Protocol | |
| 194 | TCP | irc | Internet Relay Chat Protocol | |
| 213 | UDP | ipx | IPX over IP | |
| 389 | TCP | ldap | Lightweight Directory Access Protocol | |
| 443 | TCP | S-HTTP | MCom | |
| 443 | UDP | S-HTTP | MCom | |
| 445 | TCP | Microsoft CIFS | ||
| 445 | UDP | Microsoft CIFS | ||
| 464 | TCP | kpasswd | Kerberos (v5) | |
| 464 | UDP | kpasswd | Kerberos (v5) | |
| 500 | UDP | isakmp | ike | Internet Key Exchange (IPSec) |
| 512 | TCP | exec | Remote Process Execution | |
| 512 | UDP | biff | comsat | Notifies users of new mail |
| 513 | TCP | login | Remote Login | |
| 513 | UDP | who | whod | Database of who's logged on，average load |
| 514 | TCP | cmd | shell | Automatic Authentication |
| 514 | UDP | syslog | ||
| 515 | TCP | printer | spooler | Listens for incoming connections |
| 517 | UDP | talk | Establishes TCP Connection | |
| 518 | UDP | ntalk | ||
| 520 | TCP | efs | Extended File Name Server | |
| 520 | UDP | router | router routed | RIPv.1，RIPv.2 |
| 525 | UDP | timed | timeserver | Timeserver |
| 526 | TCP | tempo | newdate | Newdate |
| 530 | TCP,UDP | courier | rpc | RPC |
| 531 | TCP | conference | chat | IRC Chat |
| 532 | TCP | netnews | readnews | Readnews |
| 533 | UDP | netwall | For emergency broadcasts | |
| 540 | TCP | uucp | uucpd | Uucpd |
| 543 | TCP | klogin | Kerberos login | |
| 544 | TCP | kshell | krcmd | Kerberos remote shell |
| 550 | UDP | new-rwho | new-who | New-who |
| 556 | TCP | remotefs | rfs rfs_server | Rfs Server |
| 560 | UDP | rmonitor | rmonitord | Rmonitor |
| 561 | UDP | monitor | ||
| 636 | TCP | ldaps | sldap | LDAP over TLS/SSL |
| 749 | TCP | kerberos-adm | Kerberos administration | |
| 749 | UDP | kerberos-adm | Kerberos administration |
http://zh.wikipedia.org/wiki/TCP/IP%E5%8D%8F%E8%AE%AE
| DHCP · DNS · FTP · Gopher · HTTP · IMAP4 · IRC · NNTP · XMPP · POP3 · SIP · SMTP · SNMP · SSH · TELNET · RPC · RTCP · RTP ·RTSP · SDP · SOAP · GTP · STUN · NTP · SSDP · BGP · RIP · 更多 |
|
TCP · UDP · TLS · DCCP · SCTP · RSVP · PPTP · OSPF · 更多 |
|
IP (IPv4 · IPv6 ) · ICMP · ICMPv6 · IGMP · IS-IS · IPsec · 更多 |
|
Wi-Fi (IEEE 802.11 ) · WiMAX (IEEE 802.16 ) · ARP · RARP · ATM · DTM · 令牌环 · 以太网 · FDDI · 帧中继 · GPRS · EVDO · HSPA · HDLC · PPP · L2TP · ISDN ·STP · 更多 |
| 以太网 · 调制解调器 · 电力线通信(PLC) · SONET/SDH · G.709 · 光导纤维 · 同轴电缆 · 双绞线 · 更多 |
下面的图表试图显示不同的TCP/IP和其他的协议在最初OSI模型 中的位置：
| 7 | 应用层 | 例如HTTP 、SMTP 、SNMP 、FTP 、Telnet 、SIP 、SSH 、NFS 、RTSP 、XMPP 、Whois 、ENRP |
| 6 | 表示层 | 例如XDR 、ASN.1 、SMB 、AFP 、NCP |
| 5 | 会话层 | 例如ASAP 、TLS 、SSH 、ISO 8327 / CCITT X.225、RPC 、NetBIOS 、ASP 、Winsock 、BSD sockets |
| 4 | 传输层 | 例如TCP 、UDP 、RTP 、SCTP 、SPX 、ATP 、IL |
| 3 | 网络层 | 例如IP 、ICMP 、IGMP 、IPX 、BGP 、OSPF 、RIP 、IGRP 、EIGRP 、ARP 、RARP 、 X.25 |
| 2 | 数据链路层 | 例如以太网 、令牌环 、HDLC 、帧中继 、ISDN 、ATM 、IEEE 802.11 、FDDI 、PPP |
| 1 | 物理层 | 例如线路 、无线电 、光纤 、信鸽 |
[root@b2cbbs ~]# grep snmp /etc/services
snmp 161/tcp # Simple Net Mgmt Proto
snmp 161/udp # Simple Net Mgmt Proto
snmptrap 162/udp snmp-trap # Traps for SNMP
snmp-tcp-port 1993/tcp # cisco SNMP TCP port
snmp-tcp-port 1993/udp # cisco SNMP TCP port
oce-snmp-trap 2697/tcp # Oce SNMP Trap Port
oce-snmp-trap 2697/udp # Oce SNMP Trap Port
websphere-snmp 3427/tcp # WebSphere SNMP
websphere-snmp 3427/udp # WebSphere SNMP
patrol-snmp 8161/tcp # Patrol SNMP
patrol-snmp 8161/udp # Patrol SNMP
suncacao-snmp 11161/tcp # sun cacao snmp access point
suncacao-snmp 11161/udp # sun cacao snmp access point
C:\Users\Administrator>ipconfig /all
C:\Users\Administrator>ipconfig /all
Windows IP 配置
主机名 . . . . . . . . . . . . . : SN-CNHQ-0303T
主 DNS 后缀 . . . . . . . . . . . : sn.suning.ad
节点类型 . . . . . . . . . . . . : 混合
IP 路由已启用 . . . . . . . . . . : 否
WINS 代理已启用 . . . . . . . . . : 否
DNS 后缀搜索列表 . . . . . . . . : sn.suning.ad
suning.ad
无线局域网适配器 无线网络连接 2:
媒体状态 . . . . . . . . . . . . : 媒体已断开
连接特定的 DNS 后缀 . . . . . . . :
描述. . . . . . . . . . . . . . . : Microsoft Virtual WiFi Miniport Adapter
物理地址. . . . . . . . . . . . . : C8-3A-35-CC-08-47
DHCP 已启用 . . . . . . . . . . . : 是
自动配置已启用. . . . . . . . . . : 是
无线局域网适配器 无线网络连接:
连接特定的 DNS 后缀 . . . . . . . : sn.suning.ad
描述. . . . . . . . . . . . . . . : 802.11n USB Wireless LAN Card
物理地址. . . . . . . . . . . . . : C8-3A-35-CC-08-46
DHCP 已启用 . . . . . . . . . . . : 是
自动配置已启用. . . . . . . . . . : 是
本地链接 IPv6 地址. . . . . . . . : fe80::5c69:1d34:1538:ac0a%23(首选)
IPv4 地址 . . . . . . . . . . . . : 10.19.113.147(首选)
子网掩码 . . . . . . . . . . . . : 255.255.240.0
获得租约的时间 . . . . . . . . . : 2013年3月19日 10:58:32
租约过期的时间 . . . . . . . . . : 2013年4月10日 20:10:06
默认网关. . . . . . . . . . . . . : 10.19.127.254
DHCP 服务器 . . . . . . . . . . . : 10.19.252.20
DHCPv6 IAID . . . . . . . . . . . : 482884149
DHCPv6 客户端 DUID . . . . . . . : 00-01-00-01-15-0C-A1-02-00-25-11-44-6F-46
DNS 服务器 . . . . . . . . . . . : 192.168.131.203
192.168.131.204
TCPIP 上的 NetBIOS . . . . . . . : 已启用
以太网适配器 VMware Network Adapter VMnet1:
连接特定的 DNS 后缀 . . . . . . . :
描述. . . . . . . . . . . . . . . : VMware Virtual Ethernet Adapter for VMnet1
物理地址. . . . . . . . . . . . . : 00-50-56-C0-00-01
DHCP 已启用 . . . . . . . . . . . : 否
自动配置已启用. . . . . . . . . . : 是
本地链接 IPv6 地址. . . . . . . . : fe80::2089:781:bbe6:221b%21(首选)
IPv4 地址 . . . . . . . . . . . . : 192.168.211.1(首选)
子网掩码 . . . . . . . . . . . . : 255.255.255.0
默认网关. . . . . . . . . . . . . :
DHCPv6 IAID . . . . . . . . . . . : 436228182
DHCPv6 客户端 DUID . . . . . . . : 00-01-00-01-15-0C-A1-02-00-25-11-44-6F-46
DNS 服务器 . . . . . . . . . . . : fec0:0:0:ffff::1%1
fec0:0:0:ffff::2%1
fec0:0:0:ffff::3%1
TCPIP 上的 NetBIOS . . . . . . . : 已启用
以太网适配器 VMware Network Adapter VMnet8:
连接特定的 DNS 后缀 . . . . . . . :
描述. . . . . . . . . . . . . . . : VMware Virtual Ethernet Adapter for VMnet8
物理地址. . . . . . . . . . . . . : 00-50-56-C0-00-08
DHCP 已启用 . . . . . . . . . . . : 否
自动配置已启用. . . . . . . . . . : 是
本地链接 IPv6 地址. . . . . . . . : fe80::8421:c5f4:bfb:5aa8%22(首选)
IPv4 地址 . . . . . . . . . . . . : 192.168.230.1(首选)
子网掩码 . . . . . . . . . . . . : 255.255.255.0
默认网关. . . . . . . . . . . . . :
DHCPv6 IAID . . . . . . . . . . . : 453005398
DHCPv6 客户端 DUID . . . . . . . : 00-01-00-01-15-0C-A1-02-00-25-11-44-6F-46
DNS 服务器 . . . . . . . . . . . : fec0:0:0:ffff::1%1
fec0:0:0:ffff::2%1
fec0:0:0:ffff::3%1
TCPIP 上的 NetBIOS . . . . . . . : 已启用
隧道适配器 isatap.{6E718F0C-8156-4D79-9283-553B6F5CCDFE}:
媒体状态 . . . . . . . . . . . . : 媒体已断开
连接特定的 DNS 后缀 . . . . . . . :
描述. . . . . . . . . . . . . . . : Microsoft ISATAP Adapter
物理地址. . . . . . . . . . . . . : 00-00-00-00-00-00-00-E0
DHCP 已启用 . . . . . . . . . . . : 否
自动配置已启用. . . . . . . . . . : 是
隧道适配器 Teredo Tunneling Pseudo-Interface:
媒体状态 . . . . . . . . . . . . : 媒体已断开
连接特定的 DNS 后缀 . . . . . . . :
描述. . . . . . . . . . . . . . . : Teredo Tunneling Pseudo-Interface
物理地址. . . . . . . . . . . . . : 00-00-00-00-00-00-00-E0
DHCP 已启用 . . . . . . . . . . . : 否
自动配置已启用. . . . . . . . . . : 是
隧道适配器 isatap.{83976C38-FD5C-4189-901D-A7DDD6495C49}:
媒体状态 . . . . . . . . . . . . : 媒体已断开
连接特定的 DNS 后缀 . . . . . . . :
描述. . . . . . . . . . . . . . . : Microsoft ISATAP Adapter #2
物理地址. . . . . . . . . . . . . : 00-00-00-00-00-00-00-E0
DHCP 已启用 . . . . . . . . . . . : 否
自动配置已启用. . . . . . . . . . : 是
隧道适配器 isatap.{902EF07A-ABB8-48F2-9F56-5E7DEE78BE58}:
媒体状态 . . . . . . . . . . . . : 媒体已断开
连接特定的 DNS 后缀 . . . . . . . :
描述. . . . . . . . . . . . . . . : Microsoft ISATAP Adapter #3
物理地址. . . . . . . . . . . . . : 00-00-00-00-00-00-00-E0
DHCP 已启用 . . . . . . . . . . . : 否
自动配置已启用. . . . . . . . . . : 是
隧道适配器 isatap.sn.suning.ad:
媒体状态 . . . . . . . . . . . . : 媒体已断开
连接特定的 DNS 后缀 . . . . . . . : sn.suning.ad
描述. . . . . . . . . . . . . . . : Microsoft ISATAP Adapter #4
物理地址. . . . . . . . . . . . . : 00-00-00-00-00-00-00-E0
DHCP 已启用 . . . . . . . . . . . : 否
自动配置已启用. . . . . . . . . . : 是
[网络性能测试]iperf适用于linux以及windows
文章引用：http://sharkyan.blog.51cto.com/536264/125016
软件下载地址：
http://sourceforge.net/projects/iperf
Iperf使用方法与参数说明
PS：这个说明是转载。
参数说明：
-s 以server模式启动。#iperf -s
-c host以client模式启动。host是server端地址。#iperf -c serverip
通用参数：
-f [kmKM] 分别表示以Kbits, Mbits, KBytes, MBytes显示报告，默认以Mbits为单位,#iperf -c 222.35.11.23 -f K
-i sec 以秒为单位显示报告间隔，#iperf -c 222.35.11.23 -i 2
-l 缓冲区大小，默认是8KB,#iperf -c 222.35.11.23 -l 16
-m 显示tcp最大mtu值
-o 将报告和错误信息输出到文件#iperf -c 222.35.11.23 -o ciperflog.txt
-p 指定服务器端使用的端口或客户端所连接的端口#iperf -s -p 9999;iperf -c 222.35.11.23 -p 9999
-u 使用udp协议
-w 指定TCP窗口大小，默认是8KB
-B 绑定一个主机地址或接口（当主机有多个地址或接口时使用该参数）
-C 兼容旧版本（当server端和client端版本不一样时使用）
-M 设定TCP数据包的最大mtu值
-N 设定TCP不延时
-V 传输ipv6数据包
server专用参数：
-D 以服务方式运行。#iperf -s -D
-R 停止iperf服务。针对-D，#iperf -s -R
client端专用参数：
-d 同时进行双向传输测试
-n 指定传输的字节数，#iperf -c 222.35.11.23 -n 100000
-r 单独进行双向传输测试
-t 测试时间，默认20秒,#iperf -c 222.35.11.23 -t 5
-F 指定需要传输的文件
-T 指定ttl值
下面的内容都是原创了：
步骤：
1.下载、scp进两个linux（一个做server一个做client）。
2.源码安装。没有特别的东西，装好了就有iperf这个命令了。
3.做server的机器上运行#iperf -s，启动iperf。 
4.做client的机器上运行#iperf -c serverip -t 30 -i 2，每2秒测试一次到serverip的网络性能，测试时间30秒。 
jperf使用：
jperf是图形界面的，安装jre（java runtime）后运行jperf.bat就可以运行。 
http://dl.iteye.com/topics/download/233daf56-ac55-3298-bd6e-da27887489fa
http://fasterdata.es.net/performance-testing/network-troubleshooting-tools/iperf-and-iperf3/
http://blog.163.com/hlz_2599/blog/static/142378474201341341339314/
https://code.google.com/archive/p/iperf/downloads
http://baike.baidu.com/view/3503290.htm
https://sourceforge.net/projects/iperf/
https://github.com/esnet/iperf
http://iperf.sourceforge.net/
网络性能测试工具iperf详细使用图文教程（原创）
http://blog.163.com/hlz_2599/blog/static/142378474201341341339314/
网络问题：其他网段网络ping不通服务器，同网段IP网络ping通服务器，问题解决
http://dl2.iteye.com/upload/attachment/0124/2145/863f15fc-3634-3c44-8801-ee4d7c7e0900.png
解决方案：
http://blog.chinaunix.net/uid-346158-id-2130939.html
windows dos机器删除全部路由信息 如：route delete 10.*
例子8：要删除目标为10.41.0.0，子网掩码为255.255.0.0的路由，执行以下命令： routedelete10.41.0.0mask255.255.0.0 例子9：要删除IP路由表中以10.开始的所有路由，执行以下命令： routedelete10.* 例子10：要将目标为10.41.0.0，子网掩码为255.255.0.0的路由的下一个跃点地址由10.27.0.1更改为10.27.0.25，执行以下命令： routechange10.41.0.0mask255.255.0.010.27.0.25
路由网关从路由表中去除导致，外界ping不通本机，本机也ping不通外界
案例二：CentOS 7.3.1611 64位 ping不通域名地址问题解决 / 动态分配地址解决方法
centos下问题：connect：network is unreachable
http://www.cnblogs.com/valu/p/6515991.html
CentOS 7.0 网卡配置及重命名教程
http://www.linuxidc.com/Linux/2017-05/143287.htm
第一步，查询本地路由表信息 [root@SCTS-PC-DEV rc.d]# route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 10.19.252.84 10.24.41.254 255.255.255.255 UGH 100 0 0 enp3s0 10.24.41.0 0.0.0.0 255.255.255.0 U 100 0 0 enp3s0 192.168.122.0 0.0.0.0 255.255.255.0 U 0 0 0 virbr0 第二步，添加默认网关，就好了。 [root@SCTS-PC-DEV rc.d]# route add default gw 10.24.41.254 [root@SCTS-PC-DEV rc.d]# route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface default gateway 0.0.0.0 UG 0 0 0 enp3s0 10.19.252.84 gateway 255.255.255.255 UGH 100 0 0 enp3s0 10.24.41.0 0.0.0.0 255.255.255.0 U 100 0 0 enp3s0 192.168.122.0 0.0.0.0 255.255.255.0 U 0 0 0 virbr0 第三步，能ping通外部IP地址和域名地址了 [root@SCTS-PC-DEV rc.d]# ping 192.168.118.201 PING 192.168.118.201 (192.168.118.201) 56(84) bytes of data. 64 bytes from 192.168.118.201: icmp_seq=1 ttl=55 time=1.55 ms 64 bytes from 192.168.118.201: icmp_seq=2 ttl=55 time=1.56 ms 64 bytes from 192.168.118.201: icmp_seq=3 ttl=55 time=1.68 ms
配置永久生效方法如下：
查看已配置的默认网关地址 [root@SCTS-PC-DEV ~]# more /etc/sysconfig/network-scripts/ifcfg-enp3s0 | grep GATEWAY GATEWAY0=10.24.41.254 [root@SCTS-PC-DEV ~]# nmcli connection show enp3s0 | grep GATEWAY IP4.GATEWAY: 10.24.41.254 IP6.GATEWAY:
CentOS 6/7网卡重启命令回顾：
CentOS 6 以下用：service network restart
CentOS 7 以上用：systemctl restart network.service
CentOS 7查看网卡：systemctl status network.service 或 service network status
CentOS 7.3.1611网卡基本配置解析：
[root@SCTS-PC-DEV ~]# more /etc/sysconfig/network-scripts/ifcfg-enp3s0 TYPE=Ethernet BOOTPROTO=dhcp DEFROUTE=yes IPV4_FAILURE_FATAL=yes IPV6INIT=no IPV6_AUTOCONF=yes IPV6_DEFROUTE=yes IPV6_FAILURE_FATAL=no IPV6_ADDR_GEN_MODE=stable-privacy NAME=enp3s0 UUID=ef3c0a14-5257-40c9-b166-2aa8ea9f2155 DEVICE=enp3s0 #物理网卡名称 ONBOOT=yes #开启自动启用网络连接设置开机启动 GATEWAY0=10.24.41.254 #设置默认网关 IPV6_PEERDNS=yes IPV6_PEERROUTES=yes PEERDNS=yes DNS1=202.102.152.3 #设置主DNS DNS2=202.102.128.68 #设置备DNS PEERROUTES=yes
案例三：centos下问题：connect：network is unreachable / 静态分配地址解决方法
http://www.cnblogs.com/valu/p/6515991.html
问题描述 弄了三台机器准备搭建一个集群，按照centos7系统，一台主节点安装桌面环境，两台计算节点。配置计算节点的时候，发现ping不通，出现connect:network is unreachable问题。 问题分析 /etc/sysconfig/network-scripts/中只有ifcfg-lo文件，缺少ifcfg-eth0。 解决方案 方案一（临时） 使用命令ifconfig eth0 192.168.1.x可以正常设置eth0的IP，该方法仅为临时处理办法，系统重启后即失效了。 方案二（永久） 第一步： vim /etc/sysconfig/network-scripts/ifcfg-eth0 第二步，编辑： DEVICE=eth0 # 物理设备名称 IPADDR=192.168.1.x #IP地址，需要设置 NETMASK=255.255.255.0 #子网掩码 GATEWAY=192.168.1.1 # 网关地址 ONBOOT=yes #激活设备 USERCTL=no #非ROOT用户不可以控制该设备 BOOTPROTO=[none|static|bootp|dhcp] #引导时不使用协议|静态分配|BOOTP协议|dhcp协议，这里我选用的是静态分配，static。 HWADDR=00:13:D3:27:9F:80 #MAC地址，通过ifconfig或者ip a获得 NAME=eth0 #名称 第三步在文件/etc/rc.d/rc.local最后加入ifup eth0（/etc/rc.local脚本是在所有其它初始化脚本执行完毕后执行）。 第四步，reboot,重启电脑.
end
hi，楼主
我认为文章上有几处错误：
1.文章提到”对于后端服务器来说，请求的源地址就是LVS的地址，加上端口会复用，所以从后端服务器的角度看，原本不同客户端的请求经过LVS的转发，就可能会被认为是同一个连接” ， 这里对LVS的原理理解有误。
在 LVS下， 对于后端RealServer来说，他看到的请求报文IP地址都是公网的客户端IP，而不是Load Balancer的。比如LVS-TUN模式就是将客户端的ip包重新用IPIP协议打包后，转发到RealServer，RealServer解包后处 理后，就可以直接将回复返回给公网的客户端（此时RealServer和LoadBalancer会共享同一个公网IP，因此可以直接回包），实际上就 LVS相当于将客户端与Load Balancer之间的TCP链接迁移到了LB选择的RealServer 。具体可以参考：http://www.linuxvirtualserver.org/zh/lvs3.html
如果是使用nginx这种应用层负载均衡的话，后端的处理server看到的报文的请求IP就是Nginx本身的IP
2. 时间戳错乱的原因搞错了。
限于实际的网络情况，很多用户的客户端没有公网IP，只能依赖于NAT分享同一个公网IP， 这样由于同一NAT下的不同机器的时间戳不一定保证同步，所以就导致同一个NAT过来的数据包的时间戳不能保证单调递增。这样就打破了RFC1323中 PAWS方法依赖于对端时间戳单调递增的要求。所以就表现为时间戳错乱，导致丢弃时间戳较小的数据包，表现为packets rejects in established connections because of timestamp的数据不断增加。所以，在LVS中的机器需要关闭tcp_tw_recycle 。