这几个网络基础问题你知道吗？

有一些东西，我们认为自己知道了，其实有可能不是这样的。以下我将列出几个基础性问题，过几天我再把我对这些问题的理解写下来。希望经过讨论大家能有一个基本准确的答案。希望大家能积极补充新问题。
1、为什么以太网要规定60字节和1514的最小包和最大包？
2、为什么ethernet II没有长度字段？
3、为什么TFTP用UDP实现的效率反而不如用TCP实现的FTP效率高？
4、为什么UDP通讯的源端口和目的端口经常是相同的数字？
5、为何很多UDP应用的数据包最大都是512字节？

第一题的解答

以太网是无连接的，不可靠的服务，采用尽力传输的机制。以太网CSMA/CD我就不多讲了，我相信大家都了解这个原理。
以太网是不可靠的，这意味着它并不知道对方有没有收到自己发出的数据包，但如果他发出的数据包发生错误，他会进行重传。以太网的错误主要是发生碰撞，碰撞是指两台机器同时监听到网络是空闲的，同时发送数据，就会发生碰撞，碰撞对于以太网来说是正常的。
我们来看一下，假设A检测到网络是空闲的，开始发数据包，尽力传输，当数据包还没有到达B时，B也监测到网络是空闲的，开始发数据包，这时就会发生碰撞，B首先发现发生碰撞，开始发送碰撞信号，所谓碰撞信号，就是连续的01010101或者10101010,十六进制就是55或AA。这个碰撞信号会返回到A，如果碰撞信号到达A时，A还没有发完这个数据包，A就知道这个数据包发生了错误，就会重传这个数据包。但如果碰撞信号会返回到A时，数据包已经发完，则A不会重传这个数据包。
我们先看一下，以太网为什么要设计这样的重传机制。首先，以太网不想采用连接机制，因为会降低效率，但他又想有一定的重传机制，因为以太网的重传是微秒级，而传输层的重传，如TCP的重传达到毫秒级，应用层的重传更达到秒级，我们可以看到越底层的重传，速度越快，所以对于以太网错误，以太网必须有重传机制。
要保证以太网的重传，必须保证A收到碰撞信号的时候，数据包没有传完，要实现这一要求，A和B之间的距离很关键，也就是说信号在A和B之间传输的来回时间必须控制在一定范围之内。IEEE定义了这个标准，一个碰撞域内，最远的两台机器之间的round-trip time 要小于512bit time.(来回时间小于512位时，所谓位时就是传输一个比特需要的时间）。这也是我们常说的一个碰撞域的直径。
512个位时，也就是64字节的传输时间，如果以太网数据包大于或等于64个字节，就能保证碰撞信号到达A的时候，数据包还没有传完。
这就是为什么以太网要最小64个字节，同样，在正常的情况下，碰撞信号应该出现在64个字节之内，这是正常的以太网碰撞，如果碰撞信号出现在64个字节之后，叫 late collision。这是不正常的。

比如第3个问题
这个和TFTP的实现有关TFTP是为了实现一种简单的文件传输而不重视效率
它在实现的时候报文的大小限制在512Bytes以内
另外它在发送接收采用的停止等待技术，也就是你发一个报文过去，对方要回应之后
你才能发下一个。所以它的传输效率远远低于TCP实现的FTP

我认为研发tftp的初衷是实现简单,他使用了停止,等待的半双工协议,而且他的数据报大小都是512byte,显然不如使用tcp的ftp来的灵活和高效.还有一个次要原因,就是在假如不太可靠的网络上面通信,tcp比udp工作的更好.

1、64字节已经解释了，1518只是因为ip的mtu为1500，加行以太网报头和fcs的18字节，就是1518
2、Ethernet II使用了类型字段，而非长度，此时协议类型既然已经知道了，当然可以根据协议类型来取走相应字段即可，同时还可以去掉繁琐的LLC、SNAP，何乐不为？另外，看到15楼解释说“另外,高层协议必须表示数据长度“，这并没有规定，比如arp就没有长度字段。实际上，大家可以想一下，当链路层知道自己封装的是什么协议，它直接送到上层对应的协议模块，上层协议自然知道哪些字段有用，而没用的部分，自然是填充内容，不作处理即可。所以，不使用长度，而用类型字段，是没有任何问题的。
3、tftp协议一次传输512字节，并且有应答报文，还有包编号，相比udp，对丢包的处理能力大大增强了，当然也就大大小损失了传输效率。所以这里不能用“因为udp效率比tcp高，所以tftp效率比ftp高“这种类推思路来思考问题！

4、为什么UDP通讯的源端口和目的端口经常是相同的数字？
在UDP中，源端口是可选参数，如果没有的话就插入0value来代替这个地方，所以可以是相同的，所以可能在某些程序中为了方便就写成一样的（猜测，本人不是做程序开发的，呵呵），但是“经常是相同”到未必，看是什么程序了(RFC768)，而且很多应用也可以根据目的IP地址，源IP地址和源端口号来过滤送往一个给定UDP端口号的数据
5、为何很多UDP应用的数据包最大都是512字节？
所有的主机必须能够重新组合最多为576字节的数据报，但实际上是应该能够重新组合与系统接口的MTU规格相同的数据报（RFC1122），因为TCP可以把数据分片，所以这个规定不会影响TCP；由于TCP/IP内核实现的限制，和那多UPD程序在设计中，应用程序数据被限制成512字节或更小。

第三个问题：

最初的TFTP协议，规定序号字段仅16bit，每个报文长度不超过512字节，自己算算是不是可能支持100M的文件传输？(答案：很多TFTP服务器限制在16MB，比如CISCO设备自己带的TFTP server、GNU tftp server。如果序号用无符号整数，最大也就32MB而已)

当然后来也有改进的TFTP可以支持比较大的文件传输，比如通过扩大报文的最大长度等方法，来支持更大一些的文件传输；又比如一些实现中，将大文件切割成32MB的n块。不过不是所有的TFTP server/client支持这些情况。

最后要说的是，由于它的运作机制，TFTP无论如何也不是一种快速可靠地传输大文件的工具