网络原理-TCP/IP(1)

应用层

我们之前编写完了基本的java socket, 要知道,我们之前所写的所有代码都在应用层中,都是为了完成某项业务,如翻译等.关于应用层,后面会有专门的讲解,在此处先讲一下基础知识.

应用层对应着应用程序,是程序员打交道最多的一层,调用系统提供的网络api写出的代码都是应用层的.

应用层这里虽然有很多协议,但程序员应该按照场景,自定义协议.(网络传输的数据要怎么用,也要考虑数据是什么格式,里面包含哪些内容).

自定义协议约定:1.服务器,客户端要交互哪些信息

                           2.数据具体格式(网络上是字符串/二进制比特流).

客户端按照上述约定发送请求,服务器按照上述约定解析请求.

服务器按照上述约定构造响应,客户端也按照上述约定解析响应.

举个例子:点餐软件

打开点餐软件,显示出主页.主页里就要显示出商家列表,而且这些商家都是附近的(打开软件的时候,就需要把你的位置告诉服务器).显示的商家列表中,也会包含一些信息:如商家名称,图片,商家的评分,商家的简介等.(交互过程中需要传输哪些信息,并不是程序员规定的,而是产品经理规定)

而这里的数据格式组织,就有了固定的套路,属于程序员的事情.

客户端和服务器之间往往要交互的是"结构化数据"(一个结构体/类:包含很多属性).

网络传输的数据其实是"字符串","二进制比特流".

约定协议的过程,就是把结构化数据转成字符串/二进制比特流的过程.

把结构化的数据,转成字符串/二进制比特流这个操作,称为"序列化".

把字符串/二进制比特流还原成结构化数据,这个操作,称为"反序列化".

序列化/反序列化具体要组织成什么样的格式,这里包含哪些信息.

约定这两件事的过程就是自定义协议的过程.

为了让程序员简单约定这里的协议格式,这里有几个供参考的方案.

xml,  json, protobuffer

这里就简单一下json,其它的如果有兴趣的话可以自行了解.

json是当今非常主流,非常常用的数据组织格式了,举个例子如下:

请求:

        {

                userId: 1000,

                position: [经纬度]

        }

响应:

        [

                {

                        id: 1001,

                        name: "老八秘制小汉堡"

                },

                {

                        id: 1002,

                        name: "初饮味来"

                }

        ]

解释:主要用到的是键值对格式. 键和值之间用 : 分割. 键值对之间用 , 分割

把若干个键值对使用{ }括起来,此时就形成了一个json对象.

还可以把多个json对象放到一起,使用 , 分割开, 并且使用[ ]整体括起来.

特性:可读性很好,扩展性也很好,通过key来对数据起到解释说明的作用.

对于xml来说解释说明是通过标签,需要有开始和结束两个标签,比较占用空间.相比之下json只使用一个key就能描述,占用的空间就比xml更少,更节省带宽了.

虽然json比xml是节省了带宽但是很明显,当前这里的带宽仍是有浪费的部分.

尤其是这种数组格式的json,这种情况下往往传输的数据字段都是相同的.使刚才这里的key名字被重复传输了.

传输层

负责数据能够从发送端到接收端.

这一层是系统内核实现好了的,提供socket的api供程序员使用.

再谈端口号

端口号(port)标识了一个主机上进行通信的不同的应用程序;

在TCP/IP协议中,用"源IP","源端口号","目的IP","目的端口号","协议号"这样一个五元组来表识一个通信.

端口号范围划分 

0-1023:知名端口号:HTTP,FTP,SSH等这些广为使用的应用层协议,他们的端口号都是固定的.

1024-65535:操作系统动态分配的端口号.客户端程序的端口号,就是由操作系统从这个范围中分配的.

认识知名的端口号

有些服务器是非常常用的,为了使用方便,人们约定一些常用的服务器,都是用以下固定的端口号:

ssh服务器,使用22端口

ftp服务器,使用21端口

telnet服务器,使用23端口

http服务器,使用80端口

https服务器,使用443

我们自己写一个程序使用端口号时,要避开这些知名端口号.

UDP协议

UDP协议端格式

我们知道,研究一个协议,主要就是研究报文格式,基于报文格式,了解这个协议其它各个属性.

UDP = 报头(重点) + 载荷(应用层数据包).

UDP报头中一共有4个字段,每个字段两个字节(一共八个字节),由于协议报头中使用两个字节表示端口号,端口号范围是: 0 ~ 65535. (这里的最大值是64kb),一旦数据超过64kb就会被截断. 

16位UDP长度, 表示整个数据报(UDP首部 + UDP数据)的最大长度;

如果校验和出错,直接丢弃. 

下面来讲解一下校验和:

校验和起到的效果,就是去尝试检查当前的数据是否存在问题.是否出现了比特翻转(网络中的校验和并非是简单的按照长度/数量作为校验标准的,一定是能让数据加入进去),就可以把错误的数据包丢掉.

简单讲一下校验的方法:

1.CRC算法完成校验(循环冗余校验):

比如要产生一个两个字节的校验和.

short checksum = 0;

for(循环遍历取出数据报中每个字节的数据) {

        checksum += 当前字节的数据;

}

加的过程,也有可能会溢出,这里也不用管.

 UDP数据报发送方,在发送之前,先计算一遍CRC,把算好的CRC值放到UDP数据报中.(设这个CRC值为value1).  接下来这个数据包通过网络传输到接收端.接收端收到这个数据之后,也会按照同样的算法,再算一遍CRC的值,得到的结果是value2.比较自己计算的value2和收到的value1是否一致.如果是一致的,就说明数据ok,如果不一致,传输过程中就发生了比特翻转了.

上述CRC算法中,如果只有一个bit位发生翻转,能够100%发现问题,但如果有两个/多个bit位发生翻转,有可能恰好校验和和之前一样.

虽然这种概率比较低,可以忽略不计,但是要想有更高的精确度,就需要其它算法了.

除了CRC,还有精度更高的md5/sha1算法.

其中md5就涉及到一系列更加复杂的数学公式了.

介绍一下MD5算法的特点:

1.定长:无论数据有多长,算出来的md5最终值为固定长度.

2.分散:计算md5时,原始数据变化一点点,计算的md5差异就会很大,(这种特性,决定md5可作为字符串的hash算法).

3.不可逆:给一个源字符串,计算md5值很简单,但要想将md5值还原为字符串,几乎无法实现.

UDP特点

UDP传输过程类似于寄信.

1.无连接:知道对端的IP和端口号就可以直接传输,不需要建立连接.

2.不可靠:没有确认机制,没有重传机制;如果因为网络故障无法发送到对方,UDP协议层也不会给应用层返回任何错误信息;

3.面向数据报:不能够灵活的控制读写数据的次数和数量.

面向数据报

应用层交给UDP多长的报文,UDP原样发送,既不会拆分,也不会合并;

用UDP传输100个字节的数据.

如果发送端调用一次sendto,发送100字节,那么接收端也必须调用对应的一次recvfrom,接收100个字节;而不能循环调用10次recvfrom,每次接收10个字节.

基于UDP的应用层协议

NFS:网络文件系统,

TFTP:简单文件传输协议

DHCP:动态主机配置协议

BOOTP:启动协议(用于无盘设备启动)

DNS:域名解析协议.

当然,也包括你写的UDP程序时自定义的应用层协议.