上一篇文章分析了互联网的总体构思，从下至上，每一层协议的设计思想。
这是从设计者的角度看问题，今天我想切换到用户的角度，看看用户是如何从上至下，与这些协议互动的。
==============================================================
互联网协议入门（二）
作者：阮一峰
（接上文）
七、一个小结
先对前面的内容，做一个小结。
我们已经知道，网络通信就是交换数据包。电脑A向电脑B发送一个数据包，后者收到了，回复一个数据包，从而实现两台电脑之间的通信。数据包的结构，基本上是下面这样：
发送这个包，需要知道两个地址：
* 对方的MAC地址
* 对方的IP地址
有了这两个地址，数据包才能准确送到接收者手中。但是，前面说过，MAC地址有局限性，如果两台电脑不在同一个子网络，就无法知道对方的MAC地址，必须通过网关（gateway）转发。
上图中，1号电脑要向4号电脑发送一个数据包。它先判断4号电脑是否在同一个子网络，结果发现不是（后文介绍判断方法），于是就把这个数据包发到网关A。网关A通过路由协议，发现4号电脑位于子网络B，又把数据包发给网关B，网关B再转发到4号电脑。
1号电脑把数据包发到网关A，必须知道网关A的MAC地址。所以，数据包的目标地址，实际上分成两种情况：
| 场景 | 数据包地址 |
| 同一个子网络 | 对方的MAC地址，对方的IP地址 |
| 非同一个子网络 | 网关的MAC地址，对方的IP地址 |
发送数据包之前，电脑必须判断对方是否在同一个子网络，然后选择相应的MAC地址。接下来，我们就来看，实际使用中，这个过程是怎么完成的。
八、用户的上网设置
8.1 静态IP地址
你买了一台新电脑，插上网线，开机，这时电脑能够上网吗？
通常你必须做一些设置。有时，管理员（或者ISP）会告诉你下面四个参数，你把它们填入操作系统，计算机就能连上网了：
* 本机的IP地址
* 子网掩码
* 网关的IP地址
* DNS的IP地址
下图是Windows系统的设置窗口。
这四个参数缺一不可，后文会解释为什么需要知道它们才能上网。由于它们是给定的，计算机每次开机，都会分到同样的IP地址，所以这种情况被称作"静态IP地址上网"。
但是，这样的设置很专业，普通用户望而生畏，而且如果一台电脑的IP地址保持不变，其他电脑就不能使用这个地址，不够灵活。出于这两个原因，大多数用户使用"动态IP地址上网"。
8.2 动态IP地址
所谓"动态IP地址"，指计算机开机后，会自动分配到一个IP地址，不用人为设定。它使用的协议叫做DHCP协议。
这个协议规定，每一个子网络中，有一台计算机负责管理本网络的所有IP地址，它叫做"DHCP服务器"。新的计算机加入网络，必须向"DHCP服务器"发送一个"DHCP请求"数据包，申请IP地址和相关的网络参数。
前面说过，如果两台计算机在同一个子网络，必须知道对方的MAC地址和IP地址，才能发送数据包。但是，新加入的计算机不知道这两个地址，怎么发送数据包呢？
DHCP协议做了一些巧妙的规定。
8.3 DHCP协议
首先，它是一种应用层协议，建立在UDP协议之上，所以整个数据包是这样的：
（1）最前面的"以太网标头"，设置发出方（本机）的MAC地址和接收方（DHCP服务器）的MAC地址。前者就是本机网卡的MAC地址，后者这时不知道，就填入一个广播地址：FF-FF-FF-FF-FF-FF。
（2）后面的"IP标头"，设置发出方的IP地址和接收方的IP地址。这时，对于这两者，本机都不知道。于是，发出方的IP地址就设为0.0.0.0，接收方的IP地址设为255.255.255.255。
（3）最后的"UDP标头"，设置发出方的端口和接收方的端口。这一部分是DHCP协议规定好的，发出方是68端口，接收方是67端口。
这个数据包构造完成后，就可以发出了。以太网是广播发送，同一个子网络的每台计算机都收到了这个包。因为接收方的MAC地址是FF-FF-FF-FF-FF-FF，看不出是发给谁的，所以每台收到这个包的计算机，还必须分析这个包的IP地址，才能确定是不是发给自己的。当看到发出方IP地址是0.0.0.0，接收方是255.255.255.255，于是DHCP服务器知道"这个包是发给我的"，而其他计算机就可以丢弃这个包。
接下来，DHCP服务器读出这个包的数据内容，分配好IP地址，发送回去一个"DHCP响应"数据包。这个响应包的结构也是类似的，以太网标头的MAC地址是双方的网卡地址，IP标头的IP地址是DHCP服务器的IP地址（发出方）和255.255.255.255（接收方），UDP标头的端口是67（发出方）和68（接收方），分配给请求端的IP地址和本网络的具体参数则包含在Data部分。
新加入的计算机收到这个响应包，于是就知道了自己的IP地址、子网掩码、网关地址、DNS服务器等等参数。
8.4 上网设置：小结
这个部分，需要记住的就是一点：不管是"静态IP地址"还是"动态IP地址"，电脑上网的首要步骤，是确定四个参数。这四个值很重要，值得重复一遍：
* 本机的IP地址
* 子网掩码
* 网关的IP地址
* DNS的IP地址
有了这几个数值，电脑就可以上网"冲浪"了。接下来，我们来看一个实例，当用户访问网页的时候，互联网协议是怎么运作的。
九、一个实例：访问网页
9.1 本机参数
我们假定，经过上一节的步骤，用户设置好了自己的网络参数：
* 本机的IP地址：192.168.1.100
* 子网掩码：255.255.255.0
* 网关的IP地址：192.168.1.1
* DNS的IP地址：8.8.8.8
然后他打开浏览器，想要访问Google，在地址栏输入了网址：www.google.com。
这意味着，浏览器要向Google发送一个网页请求的数据包。
9.2 DNS协议
我们知道，发送数据包，必须要知道对方的IP地址。但是，现在，我们只知道网址www.google.com，不知道它的IP地址。
DNS协议可以帮助我们，将这个网址转换成IP地址。已知DNS服务器为8.8.8.8，于是我们向这个地址发送一个DNS数据包（53端口）。
然后，DNS服务器做出响应，告诉我们Google的IP地址是172.194.72.105。于是，我们知道了对方的IP地址。
9.3 子网掩码
接下来，我们要判断，这个IP地址是不是在同一个子网络，这就要用到子网掩码。
已知子网掩码是255.255.255.0，本机用它对自己的IP地址192.168.1.100，做一个二进制的AND运算（两个数位都为1，结果为1，否则为0），计算结果为192.168.1.0；然后对Google的IP地址172.194.72.105也做一个AND运算，计算结果为172.194.72.0。这两个结果不相等，所以结论是，Google与本机不在同一个子网络。
因此，我们要向Google发送数据包，必须通过网关192.168.1.1转发，也就是说，接收方的MAC地址将是网关的MAC地址。
9.4 应用层协议
浏览网页用的是HTTP协议，它的整个数据包构造是这样的：
HTTP部分的内容，类似于下面这样：
GET / HTTP/1.1
Host: www.google.com
Connection: keep-alive
User-Agent: Mozilla/5.0 (Windows NT 6.1) ......
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Encoding: gzip,deflate,sdch
Accept-Language: zh-CN,zh;q=0.8
Accept-Charset: GBK,utf-8;q=0.7,*;q=0.3
Cookie: ... ...
我们假定这个部分的长度为4960字节，它会被嵌在TCP数据包之中。
9.5 TCP协议
TCP数据包需要设置端口，接收方（Google）的HTTP端口默认是80，发送方（本机）的端口是一个随机生成的1024-65535之间的整数，假定为51775。
TCP数据包的标头长度为20字节，加上嵌入HTTP的数据包，总长度变为4980字节。
9.6 IP协议
然后，TCP数据包再嵌入IP数据包。IP数据包需要设置双方的IP地址，这是已知的，发送方是192.168.1.100（本机），接收方是172.194.72.105（Google）。
IP数据包的标头长度为20字节，加上嵌入的TCP数据包，总长度变为5000字节。
9.7 以太网协议
最后，IP数据包嵌入以太网数据包。以太网数据包需要设置双方的MAC地址，发送方为本机的网卡MAC地址，接收方为网关192.168.1.1的MAC地址（通过ARP协议得到）。
以太网数据包的数据部分，最大长度为1500字节，而现在的IP数据包长度为5000字节。因此，IP数据包必须分割成四个包。因为每个包都有自己的IP标头（20字节），所以四个包的IP数据包的长度分别为1500、1500、1500、560。
9.8 服务器端响应
经过多个网关的转发，Google的服务器172.194.72.105，收到了这四个以太网数据包。
根据IP标头的序号，Google将四个包拼起来，取出完整的TCP数据包，然后读出里面的"HTTP请求"，接着做出"HTTP响应"，再用TCP协议发回来。
本机收到HTTP响应以后，就可以将网页显示出来，完成一次网络通信。
这个例子就到此为止，虽然经过了简化，但它大致上反映了互联网协议的整个通信过程。
（完）
水绿如蓝 说：
看过阮老师的互联网协议入门两篇文章，受益匪浅，上大学时候就一直好奇这个问题，问周围同学没人能讲得清楚，即使有的人真懂也不知道该怎么表达。直到今天才茅塞顿开，呵呵，发现每一个系统都是因为有了N多的保障才完好运行的，不容易啊，智慧是个好东西。
2012年6月11日 19:19 | # | 引用
水绿如蓝 说：
发现外专业来理解IT专业的很多事情确实还是挺困难的。那个0和1也比较让人纠结，不知是怎么个道理；还有比如一些漂亮的网页，那些图像啦颜色了是靠什么来规定的；再有N多不同种类的程序如何实现自己的功能……这些对我们单纯的使用者而言真的是极难搞懂的事情。
2012年6月11日 19:22 | # | 引用
锐齿猱 说：
我网速好慢，不知道什么原因。
2012年6月11日 20:04 | # | 引用
xavierskip 说：
以前不太懂，网关和子网掩码的作用。现在明白了。因为整个网络是很庞大的，由不同的子网组成的。不同的子网之间是不能直接进行通信的，需要转发中转，这时候网关和子网掩码就要起作用了。我是这么理解的。
2012年6月11日 21:31 | # | 引用
爱早起 说：
网速慢有多种原因，最可能的是你使用的网络本来带宽就很小，比如1M。
另外，如果你开了很多要联网的软件，比如迅雷下载之类的，也会占用较多网速。
2012年6月11日 21:35 | # | 引用
codebook 说：
1：8.3 DHCP协议中“才能确定是不是发过自己的”是不是应该是“发给”
2：9.3 子网掩码中“做一个二进制的AND运算（两个数位相同，结果为1，否则为0）”括号中的解释应该是同或运算
2012年6月11日 21:41 | # | 引用
reverland 说：
插图是拿什么画的，好漂亮
2012年6月11日 21:53 | # | 引用
依云 说：
看样子是著名的 Photoshop。
2012年6月12日 00:47 | # | 引用
LUO 说：
PPT也可以做出这种效果，其他专业图好像是office的visio做的。
2012年6月12日 00:54 | # | 引用
xiph 说：
受益匪浅。我读的不是相关专业，但对计算机，互联网都非常感兴趣，现在刚刚开始接触，正在学习编程，精力有限，开始时对技术的了解肯定有一定的局限性，希望阮老师可以写更多这类条理清晰，较容易理解的技术文章，对我们的帮助很大，感谢。我是读金融的，期待您有更多经济学方面的文章。
2012年6月12日 02:11 | # | 引用
胡小易 说：
这篇文章有点白了，不过讲的不错哈
2012年6月12日 06:29 | # | 引用
阮一峰 说：
谢谢指出，已经更正了。
2012年6月12日 07:27 | # | 引用
刘永新 说：
阮老师的技术文章就是简洁明了！
2012年6月12日 08:11 | # | 引用
阿Pon 说：
阮老师的文章真好，以前是半懂不懂，看完后有点豁然开朗的感觉。
2012年6月12日 11:24 | # | 引用
Q 说：
为什么你用window$?
2012年6月12日 11:35 | # | 引用
阿Pon 说：
9.8 服务器端的响应 google读出“HTTP请求”后，接着做出"HTTP响应"，再用TCP协议发回来。
这个过程中，是不是先发到我所在子网络的网关，再通过网关发送到我的主机呢？希望阮老师能说详细点，不是很明白。
2012年6月12日 11:46 | # | 引用
依云 说：
是的，有很多软件都能够做出这种效果，所以看图的效果是得不到结论的。
如果不是伪造的信息的话，那些图是用 Photoshop CS5 Windows 版做的。
2012年6月12日 12:34 | # | 引用
GeHou 说：
NICE啊，感谢大大的分享!!!
2012年6月12日 15:41 | # | 引用
幽灵 说：
“当看到发出方IP地址是0.0.0.0，接收方是255.255.255.255，于是DHCP服务器知道"这个包是发过我的"，而其他计算机就可以丢弃这个包。”
还是有错别字，应为“这个包是发给我的”。
希望博主在发表文章之后，认真仔细得再读一遍。
2012年6月12日 21:52 | # | 引用
yava 说：
数据包到了网关之后是怎么处理的呢？ google服务器只能获取到外网ip，获取不到局域网ip 192.168.1.100
2012年6月13日 09:26 | # | 引用
阮一峰 说：
谢谢指出，已更正。
啊，我疏忽了，忽略了内外网IP地址转换的问题。
192.168.1.100这个例子举得不好，如果改成通用IP地址，就不存在转换问题，Google的服务器就能得到这个地址了。
因为这个问题涉及的地方比较多，要等到下一次修订本文的时候，我再一次性全部改掉。
2012年6月13日 11:19 | # | 引用
cccc 说：
能讲下IPv6的网络吗？
2012年6月14日 07:42 | # | 引用
oliver 说：
期待您的内外网地址转换的文章。
2012年6月16日 23:27 | # | 引用
cdk 说：
感谢，阮爷教诲！
2012年6月18日 08:32 | # | 引用
bailey 说：
受益匪浅
2012年6月18日 13:53 | # | 引用
cpluse 说：
不能付费支持了？跳到支付宝“暂停担保买卖业务的公告”了
2012年6月20日 23:32 | # | 引用
阮一峰 说：
改好了，跳转到支付宝个人收费主页了。
2012年6月21日 08:07 | # | 引用
wugr 说：
看过了1，就等着看2，呵呵～对我来说，1的内容深入浅出，非常不错！当然，2也不错～
2012年6月26日 21:53 | # | 引用
Robinson 说：
呵呵，终于出来了。文章写得相当好，我存在我的为知笔记里了，地铁上没事的时候就拿出来看看。
2012年6月30日 00:48 | # | 引用
木树 说：
看了阮哥的文章，才知道世界上的天才离我是那么的近，是那种触手可及的，而不是站在云端那种。
2012年6月30日 01:18 | # | 引用
Kerry 说：
以太网数据包的数据部分，最大长度为1500字节，而现在的IP数据包长度为5000字节。因此，IP数据包必须分割成四个包。因为每个包都有自己的IP标头（20字节），所以四个包的IP数据包的长度分别为1500、1500、1500、560。
+++++++++++
是不是也要加上ethernet包的head呢？？？应该是1500，1500，1500，640把
2012年7月16日 23:40 | # | 引用
D瓜哥 说：
看来阮老师的博文，觉得原来零碎的互联网协议知识才有了一个整体的感觉。不过，可能是自己对协议的知识了解的只是一知半解，所有有些东西还要下去再用功！
期待阮老师内外网转换的文章！！
2012年7月18日 10:20 | # | 引用
Leo 说：
最后，IP数据包嵌入以太网数据包。以太网数据包需要设置双方的MAC地址，发送方为本机的网卡MAC地址，接收方为网关192.168.1.1的MAC地址（通过ARP协议得到）。
第一篇文章中说如果不在一个网络内获取对方的MAC地址要交给网关处理，这个处理能解释一下么？还是有后续的文章
2012年7月18日 16:37 | # | 引用
Airomyas 说：
192.168.* 是保留地址，不允许在Internet上出现，一般用作内网。内网与外网之间可以通过NAT协议进行转换。
一个IP包从本地网络到达Google的服务器，中间需要经过多个路由器，而不是网关。
2012年7月26日 16:52 | # | 引用
juqkai 说：
受益匪浅呀, 但是有个疑问.
我是一个在内网的接收方, 发送方要发送什么样的地址我才能收到呢? 因为在IP里面只有一个我的内网地址, 而以太包里面也只有我的IP. 内网IP在全球这么多个, 它是怎么找到我的呢? 肯定不是通过MAC来找的吧, 那么, 是不是每经过一个路由, 就会在里面再封装一层地址呢? 最终发送方发出的会不会是一串IP, IP, IP, IP, IP的链接呢?
2012年8月17日 15:36 | # | 引用
xueshi 说：
写的真心不错，每一个地方都讲解的很清楚，还有一个地方没有讲清楚，还拿最后一个例子来说，“最后，IP数据包嵌入以太网数据包。以太网数据包需要设置双方的MAC地址，发送方为本机的网卡MAC地址，接收方为网关192.168.1.1的MAC地址（通过ARP协议得到）”，发送到192.168.1.1，网关应该还会拆开包，根据子网掩码与操作发现不是在一个内网内，那么将会重新把这个包封装一下，接收方的为它的网关的MAC地址，就这样一层一层往上面找，最终到一个网关，网关根据子网掩码发现172.194.72.105（Google）和自己在一个内网内，然后将请求发给172.194.72.105（Google），这样就到达了目的地
2012年10月 3日 21:13 | # | 引用
兵临城下 说：
简介明了，最主要的是成体系！
2012年10月24日 14:28 | # | 引用
郭春阳 说：
如果不在一个网络内是不需要获取对方MAC的，因为MAC地址适用于同一网段通信的。
需要的是网关的MAC，因为你要首先和网关通信。
2012年11月 3日 11:06 | # | 引用
御宅暴君 说：
今天在学计算机网络，特此温习了下。
讲得真精彩，受益匪浅！
2013年3月23日 19:17 | # | 引用
Zernel 说：
讲得很清晰，虽然这些知识以前学计算机网络的时候都有学过，不过现在看完还是有种豁然开朗的感觉，相当不错！
2013年4月 6日 15:29 | # | 引用
第04号 说：
你好！
很感激你整理出这么深入浅出的文章分享给大家！受益匪浅！
文中有一部分我有些不解，希望能获得一点指教！
文中讲到，以太网协议的时候，例中一个IP协议数据包要被分为4个包，但是每个包都需要有IP协议段。这一点是怎么做到的呢？是通过解析提取其中的IP协议段数据然后复制吗？我的疑问是下一层的协议不应该知道有高一层协议的存在，不应该为上一层负责，所以感觉不合理。
对此我的猜测可能的解释是，在实际中传输层协议实现的时候是直接负责数据打包成以太网数据包，所以整个过程在内部是清晰可见的，所以可以完成这个任务。
请问是那种情况使得他运转正常呢？希望能得到指教。
2013年4月15日 15:54 | # | 引用
3null 说：
这两篇文章看下来，对整个互联网通信有个比较清晰的印象了。原来概念都很混乱，感谢老师写这么好的文章！
2013年5月16日 17:57 | # | 引用
veiky 说：
“根据IP标头的序号，Google将四个包拼起来，取出完整的TCP数据包，然后读出里面的"HTTP请求"，接着做出"HTTP响应"，再用TCP协议发回来。”
Google的服务器收到数据包的时候，它能得到所有路由中间过程吗？它收到的数据包中源IP地址和源MAC是我本机的呢，还是离它最近的那级网关的？怎么一级一级的发回来呢？
“……再用TCP协议发回来。” 这句话说的太简单了，谁给咱菜鸟讲解下？
2013年7月15日 13:43 | # | 引用
beamingmax 说：
真心清楚，阮老师，希望您能出一些IT方面的科普读物。
2013年9月12日 14:54 | # | 引用
莽原 说：
通俗易懂，太厉害了，由于不是该专业的，之前看了很多这方面的东西，都完全整明白，看完这篇有了一个整体框架，太爽了，多谢！！
2013年11月13日 21:26 | # | 引用
凡客 说：
应该也是经过了很多网关，但是不一定是和原来的路走相同的，最终达到了本地网关，网关然后转发给本地pc。
2013年12月21日 09:26 | # | 引用
Dingo妹 说：
好文章，支持阮老师。
2013年12月29日 23:35 | # | 引用
dipqib 说：
很适合我这样的菜鸟看啊！
建议多用些图解。
2014年1月12日 16:32 | # | 引用
欧文 说：
阮老师总是能把复杂的问题简化，讲的有条有理，来龙去脉都非常清楚，这样就什么容易记。
2014年3月27日 19:02 | # | 引用
wind 说：
神教程,不解釋.果然是高手!
能把抽象的事物具象化,並且能夠讓普通人一看就明白,你絕對有當一個優秀導師的天賦.
感謝好文!
2014年5月29日 14:40 | # | 引用
张海鹏 说：
最近一直在研究阮老师的博客，因为大学的计算机课程基本上已经学完了，但是没有形成体系，很多东西都只能站在一个切面看问题，没有立体的看过，尤其是分层思想把握的不是很好，刚刚读完第三CSAPP，结合阮老师的文章，感觉对体系的认识逐渐在加深。我有一个想法：可不可以扩展你提出的Google的例子，然后从物理层到应用层进行更加详尽的分析和描述，从足够细致的角度来理解，因为自己在做另一件事情，就是解释简单的“Hello World”的从编译到OS到底层硬件的执行过程！
2014年6月 1日 13:56 | # | 引用
apacal 说：
好文章，结合wireshark抓包，tcp/ip协议详解来学习，以前没有连贯起来。
2014年9月28日 11:13 | # | 引用
dreamy 说：
之前单一的学习了各个部分的知识，很多东西知道了应该是什么，但为什么是这样，经博主把整个知识脉络串联起来，豁然开朗。
2014年10月 3日 10:01 | # | 引用
Boatman 说：
2014年10月14日 10:23 | # | 引用
cike8899 说：
博主，你的博客为啥美誉目录呢，不好查找我想看的内容！
2014年11月20日 14:20 | # | 引用
myth 说：
看了两遍,出去具体实现细节,头脑中已经有大致过程了
2015年1月 3日 13:14 | # | 引用
nian 说：
"以太网数据包的数据部分，最大长度为1500字节，而现在的IP数据包长度为5000字节。因此，IP数据包必须分割成四个包。因为每个包都有自己的IP标头（20字节），所以四个包的IP数据包的长度分别为1500、1500、1500、560"
最后一个为什么是560不是500呢？想不通。。
2015年1月 9日 15:29 | # | 引用
小毛 说：
很有意义，获益很大
2015年3月 3日 10:39 | # | 引用
wayne 说：
谢谢，受益匪浅！
2015年3月 6日 13:07 | # | 引用
Ivan 说：
真是好文章，我真的很好奇，是怎么在短时间内，找到一个技术问题的本质与精髓的呢，难道是大量阅读？但是没有效率啊，一定有一些特别行之有效的学习方法，希望阮兄不吝赐教。
2015年7月21日 19:17 | # | 引用
MG 说：
清晰易懂. 先点个赞.
关于DHCP服务器发送offer给client,貌似即可以广播也可以单播.
而且DHCPOFFER的目标IP地址,从我抓的wireshark trace来看, 貌似是新分配的IP地址,而不是文中的255.255.255.255.
2015年8月15日 14:47 | # | 引用
pestd 说：
阮老师的博文浅显易懂，受益匪浅，非常感谢分享！
2015年9月11日 15:48 | # | 引用
iMusicDog 说：
写的通俗易懂！以前学过，现在重温一遍挺好的，新的收获是在DHCP过程，以前真的没分析过这个过程，以自动获取一笔带过了。感谢！
2015年12月19日 23:56 | # | 引用
iMusicDog 说：
应该是500
2015年12月20日 00:31 | # | 引用
嗯，说没说完全，应该是两个数位同为1才得1，否则的0 说：
2016年1月15日 17:37 | # | 引用
蒋小家 说：
阮老师, 请问你平时都是如何接触, 学习, 熟悉新的知识的? 能否写一篇关于自我学习方面的文章, 谢谢!
2016年2月14日 01:36 | # | 引用
雁南飞 说：
经典
2016年3月11日 15:12 | # | 引用
罹伤 说：
豁然开朗
2016年3月14日 11:17 | # | 引用
Linin 说：
好文章不会随着时间而流逝
2016年3月19日 21:49 | # | 引用
昔班 说：
峰哥，请收下我的腿
2016年6月 1日 22:15 | # | 引用
ArJo 说：
DNS服务端口不是53么？
2016年8月 8日 13:00 | # | 引用
-random 说：
计算机网络知识一窍不通，还是得慢慢补。。。。
2016年8月 9日 16:14 | # | 引用
泡面搭档Ted 说：
是560。
5000的IP报文里已经包含1个IP头（20），分4次发，那么还需要3个IP头（60），共需要发5000 + 60 = 5060 = 1500 + 1500 + 1500 + 560
另外，以太网帧MTU指的是数据部分，不包括头
2016年8月28日 22:24 | # | 引用
龙飞凤舞 说：
好像确实有点问题。。。
1.IP数据包长度为5000字节 。
2.由于以太数据区最长为1500字节，然后拆分如下：
①20字节IP标头+1480字节的IP数据=1500
②20字节IP标头+1480字节的IP数据=1500
③20字节IP标头+1480字节的IP数据=1500
④20字节IP标头+560字节的IP数据=580
不知道这个对吗？
@阮一峰 如果回复可以有图片是不是好一点，或者网站上加一个用户注册功能：）
2016年8月31日 10:36 | # | 引用
hazhade 说：
阮老师一语解疑惑；之前一直弄不明白；百度也各种迷糊；老师的思路清晰明了；
2016年9月 1日 14:24 | # | 引用
Gzy 说：
1. IP数据包长度为5000字节 ＝ 20字节IP标头 ＋ 4980字节的IP数据。
2. 由于以太数据区最长为1500字节，然后拆分如下：
①20字节IP标头+1480字节的IP数据=1500
②20字节IP标头+1480字节的IP数据=1500
③20字节IP标头+1480字节的IP数据=1500
④20字节IP标头+540字节的IP数据=560
2016年9月 8日 16:21 | # | 引用
铁鸟 说：
阮老师讲的太好了 一晚上让我搞明白许多多年模糊不清的东西 很多知识虽然复杂 但如果真心实意想讲清楚还是有办法的 可惜现实中很多书和资料要么冠冕堂皇 生硬教条 七拼八凑 应付差事 要么讲到关键地方就不讲了 有时候关键的东西就几句话 或者举个例子能说明白 但他们就是不说 喜欢装 故弄玄虚 有意无意都要留一手 这不是少数 是大多数 这也许是人性或体制造成的… 所以阮老师这样的人真是太少了 既有学识又有真心 真的非常感谢和敬佩！！！
2016年9月11日 00:54 | # | 引用
David 说：
科普好文章。赞你！！
2016年9月17日 14:31 | # | 引用
七寸 说：
每天读一篇阮老师的文章 受益匪浅
2016年10月24日 14:17 | # | 引用
前端_菜鸟 说：
我也觉得这个地方说的有点问题，但是我不明白的是：第一次连网，比如我带着笔记本去KFC蹭网，当我连上了KFC的wifi之后，就可以上网了，也就是DHCP会自动给我的笔记本返回一个ip地址，这个过程是不是瞬间完成的呢？还有请问下你是怎么用抓包看到返回的ip的呢？（或许我对连网的这个过程理解有误，还请指正！）
2016年10月24日 17:01 | # | 引用
前端_菜鸟 说：
我也觉得这个地方说的有点问题，但是我不明白的是：第一次连网，比如我带着笔记本去KFC蹭网，当我连上了KFC的wifi之后，就可以上网了，也就是DHCP会自动给我的笔记本返回一个ip地址，这个过程是不是瞬间完成的呢？还有请问下你是怎么用抓包看到返回的ip的呢？（或许我对连网的这个过程理解有误，还请指正！）
2016年10月25日 10:25 | # | 引用
东根 说：
阮老师，您好。两篇文章我翻来翻去的看，有一处不明白。
如何获得google服务器的网关MAC地址？？
2016年10月26日 16:57 | # | 引用
ains7 说：
联通移动电信 在互联网中扮演什么角色？为什么要给他们缴费？他们是干啥的！网关吗？不通过这些公司就不能上网吗？
2016年11月 7日 04:23 | # | 引用
将军 说：
赞赞赞，讲的很好，通俗易懂
2016年11月12日 09:51 | # | 引用
惯看秋月春风 说：
听君一席话，顿开茅塞。
2016年11月14日 10:32 | # | 引用
方小文 说：
2017年1月10日 03:07 | # | 引用
Sansis 说：
网站的IP地址可以通过DNS获取，那如果一台计算机想和另一台计算机通信（不是网站），怎么知道对方的IP地址呢？
2017年2月27日 18:10 | # | 引用
Sansis 说：
是在网络设置里看么？你把网络关掉，网络设置里v4IP就变空了，再连上有能看到自己的IP了。
2017年2月27日 18:13 | # | 引用
梁炜东 说：
阮老师，首先非常谢谢你，看了你的这两篇感觉互联网整体通信理解了，非常谢谢你。
但是我还有一个问题不理解：
就是我们都说TCP协议的链接需要进行三次握手，这个我可以理解，就是tcp规定的嘛，为了保证通信的准确性（我是这么理解的），但是我不明白的是为什么tcp的链接的三次握手必须是客户端发起，原则上客户端和服务端不都是计算机嘛，根据博客讲的都可以发起的，都可以互相通信的，为什么到了这里就是必须是客户端发起通信啊？ 这就让我想起来了我们平时说的长链接，如果不必须是客户端发起，要什么长链接啊，服务端也可以主动给客户端发。
希望阮老师能够帮我解答一下，谢谢
2017年3月10日 11:57 | # | 引用
左仁珂 说：
@梁炜东：
先有请求，才有客户端和服务端的定位。发送请求方为客户端，接受方为服务端。所以，你说的服务端发送，那么服务端我们就可以称之为客户端
2017年3月27日 18:49 | # | 引用
Cathy 说：
阮老师说的任何东西都是易懂的，太厉害了！这对非科班出身的小白来说真是福音，谢谢！
2017年4月20日 14:30 | # | 引用
朱红枫 说：
我也纳闷
2017年4月21日 17:12 | # | 引用
大头 说：
ARD协议进行地址转化
2017年4月26日 13:29 | # | 引用
zzzz76 说：
吐个槽，不知道评论里为什么这么多人说通俗易懂的
只看出了大致过程，每个点都是点到即止，自己画个图在每个点都莫名其妙，这篇文章最多只能作为学成后的回顾来读吧，之前没看过网络的我是难以理解，也希望各位小白不要被评论带偏了,文章并没有那么通俗，回去先啃啃书再来吧
2017年6月10日 20:44 | # | 引用
w3c0929 说：
看到很多人都在想这个问题，我想应该是这样的
http数据包(4960)
-->TCP数据包(4980)
-->IP数据包(开始分割成4个包，每个包占标头20,4980+20*4所以总长5060)
-->四个以太网数据包：1500,1500,1500,560
2017年6月22日 05:26 | # | 引用
黄天天 说：
读完您的这两边文章，真的是豁然开朗。
2017年7月19日 17:13 | # | 引用
Lp 说：
有一个疑问，当只知道对方网址，需要通过DNS服务器获取对方IP的时候，是需要往DNS服务器发送数据包，那么按照协议，以太网标头中的DNS服务器的MAC地址如何获取？ 如果DNS服务器和当前PC在同一个网络可以根据ARP协议来获取？但若DNS服务器跟当前PC不在同一个子网络中呢，那如何往DNS服务器发送数据包来解析网址,也是要通过网关转发的吗？ 小白一个，不知道问题提的是否恰当。
2017年8月 3日 15:37 | # | 引用
sendtion 说：
@梁炜东：
服务端和客户端是相对的，谁发起请求谁就是客户端，服务端也可以发起请求的。现在是我要向服务器请求数据，那么我就是客户端。
2017年8月11日 16:24 | # | 引用
张治刚 说：
简洁明了 概括到位 受益匪浅 我会一直在这里学习下去的 谢谢阮老师！！
2017年8月17日 12:47 | # | 引用
Aaron 说：
我只能说，震撼，我找了好久的都没找到这样一气呵成的。大多数文章都是分散的说各个层，没有串联到一起，根本不知所云。给跪，非常有帮助。
2017年9月 6日 11:14 | # | 引用
三叶 说：
“DHCP服务器读出这个包的数据内容，分配好IP地址，发送回去一个"DHCP响应"数据包。这个响应包的结构也是类似的，以太网标头的MAC地址是双方的网卡地址，IP标头的IP地址是DHCP服务器的IP地址（发出方）和255.255.255.255（接收方）”这里由DHCP响应回去的，接受IP不应该是0.0.0.0么，255.255.255.255是指的它本身？
2017年9月20日 21:21 | # | 引用
LYT 说：
阮老师：
你好，看过你的tcp协议，和互联网协议（一，二），总算是理通了请求的过程，现在有一个问题需要您来解答，您上边说的，不在同一个子网，不能使用ARP协议来获取对方的MAC地址，需要用到网关，我想问一下，另外一个网关是怎么获取到的，是通过ip获取的还是？希望您能回复。
2017年12月 1日 17:00 | # | 引用
沉默 说：
TCP数据头应该也要加到分片里面吧,不然后三个分片就没有TCP数据头信息了,我认为应该是4960+(20+20)*4 = 5120吧
2017年12月16日 11:05 | # | 引用
吴方波 说：
阮老师的互联网协议入门两篇文章对网络协议初学者是一大贡献。本人近80岁，退休后一直学习数字电路，汇编语言，高级语言等。唯独网络协议感到很难理解，原因是以往那些网络协议的文章太专业，感谢阮老师的所做的贡献。
2018年3月21日 21:23 | # | 引用
饼干 说：
“经过多个网关的转发，Google的服务器172.194.72.105，收到了这四个以太网数据包。”
读到这里时，我脑海中想到的是西游记师徒四人终于到达西天的场景。某种意义上来说，取经也算是一次request/response吧
2018年4月16日 17:15 | # | 引用
疯狂de菜狗 说：
前辈这段话让晚辈更加坚定终生学习这个信念。
2018年4月27日 17:42 | # | 引用
Hopetree 说：
受益匪浅，特别是关于网关和IP地址的关系，讲的很通俗易懂
2018年5月 2日 15:47 | # | 引用
墨斗鱼 说：
以太网数据包需要设置双方的MAC地址，发送方为本机的网卡MAC地址，接收方为网关192.168.1.1的MAC地址（通过ARP协议得到）。
之前只介绍了同一个子网下如何通过ARP协议得到MAC地址，那不是同一个子网下，如何通过ARP协议得到网关的MAC地址呢？
2018年10月 9日 17:02 | # | 引用
学习学习 说：
9.7 最后一个数据包应该是580字节吧
2018年10月19日 21:20 | # | 引用
小鑫 说：
@juqkai：
IP header 有长度限制，不可能无限这么append 下去的，而且也不科学。
这一步是路由表维护的，你可以看看这个(路由拓扑):
https://docs.oracle.com/cd/E19683-01/806-4075/ipplan-1/index.html
2018年12月13日 15:31 | # | 引用
L 说：
讲的还是太浅了，ip报文头的结构，tcp报文头结构
三次握手，四次挥手这些都没讲。。只能说给完全不懂的人科普一下吧
另外最后一个例子里，ip头里面是没有数据包序号的
要把乱序的数据包按照顺序读取，是tcp协议要做的事情
2019年1月15日 22:38 | # | 引用
张小吉 说：
“普通用户望而生畏，而且如果一台电脑的IP地址保持不变，其他电脑就不能使用这个地址，不够灵活”应该还有一个更重要的原因，是ipv4数量不够用了
2019年1月30日 16:40 | # | 引用
Chengyu 说：
非常感谢这两个帖子！通俗易懂！
2019年3月 4日 04:34 | # | 引用
awner 说：
有两个问题。
同个子网内把包广播，每个网卡都能收到这个包，那是如何保证信息的安全？
会不会存在子网掩码andip后相同，但事实上并不在同一个子网的情况。
2019年3月12日 18:23 | # | 引用
小菜鸡 说：
是的，我也一直想不明白这个包的算法，我也觉得应该是5120，因为还有端口数据呢（tcp标头）。或者有什么我们不知道的内部处理机制吧，这4个包有关联机制，不然，其他3个没有端口的包怎么发到服务器呢？
2019年5月 4日 20:58 | # | 引用
张俊凯 说：
@龙飞凤舞：
第一个标头的20已经属于5000之内了，需要拆分的数据是3500，接下来的每一个包只能装1480，那就是 1500 + 1480 + 1480 + 540 = 5000
2019年5月16日 15:50 | # | 引用
Welch 说：
9.7 以太网协议
最后一句话“四个包的IP数据包的长度分别为1500、1500、1500、560”，我觉得四个包的长度应该分别为1500、1500、1500、580.
2019年6月30日 22:19 | # | 引用
Siegfried 说：
讲的非常好！
很难想象，这么复杂的流程，会在毫秒级别，完成一次http通信，真的太神奇了。
2019年9月24日 15:25 | # | 引用
Wang Pengfei 说：
2019年11月 7日 09:09 | # | 引用
Liu 说：
复习（预习）计网想先理清整体结构层次，就想找一个例子，刚好看到这篇！真的好
2020年1月 7日 00:47 | # | 引用
WHUTlyd 说：
自己以前没怎么系统学习过网络方面的知识 正准备看书学习下 发现了阮老师的两篇文章 用心读了下写的真好！ 算是入个门，加油。
2020年5月14日 10:34 | # | 引用
zy 说：
写得太好了，看这么一个教程等于看了好几遍大部头
2020年6月21日 22:23 | # | 引用
无需有太多 说：
google给响应的时候是怎么找到我们的电脑的呢？是请求时就建立好连接了吗？
2021年6月22日 11:23 | # | 引用
myhlcb 说：
阮老师写的很明了，另外这部分要结合上一篇一起来看，我的理解是这样的
还是那个本机与google通信的例子，知道本机的mac地址和google的ip地址那么
* 本机-->本机的网关-->google的网关
* 从google网关里面根据ARP协议找到172.194.72.105对应的mac地址之后就实现了通信
2021年10月19日 15:57 | # | 引用
leoperfect 说：
接下来，DHCP服务器读出这个包的数据内容，分配好IP地址，发送回去一个"DHCP响应"数据包。这个响应包的结构也是类似的，以太网标头的MAC地址是双方的网卡地址，IP标头的IP地址是DHCP服务器的IP地址（发出方）和255.255.255.255（接收方）
------
接收方IP地址 255.255.255.255 应该是真实的IP地址。因为IP地址已经给分配好了
2022年1月13日 17:21 | # | 引用
Fengyu 说：
这才是学问，循序渐进。上课上来七层模型 怎么来的一概不说 搞得似懂非懂的。现在的某些大学教育是大问题
2022年3月19日 10:25 | # | 引用
周叹 说：
太受用啦感谢大神
2022年8月18日 15:52 | # | 引用