今日内容:
1、tcp协议详解=》可靠协议(******)
udp协议=》不可靠协议
2、上网的通信流程
3、socket编程
开发一个基于tcp协议通信的应用程序
==============================> 昨日内容补充 <========================================
数据链路层:
单纯的电信号无意义,所以要进行分组
Ethernet:长度
头:固定长度
每台计算机必须要有网卡,每个网卡上有一个独一无二的mac地址
五层的下面四层 是操作系统提供好了的
可以通过调用操作系统的服务 执行 下面四层工作的相关参数 ; 而 这个与操作系统的下面四层打交道的 就是socket应用程序,它手里握着操作系统提供的钥匙,所以不用时,应该释放掉手里的资源(也即操作系统的资源)
=============================> tcp 与 udp协议====================================
1、tcp
计算机之间联络的相关标志:
syn=1 :请求信息
建立从自己到对方的桥梁
or
拆除从自己到对方的桥梁
ack=1 :确认信息
同意建立从对方到自己的桥梁
or
同意拆除从对方到自己的桥梁
seq:判断信号
通过seq(起判断作用): 判断收到的包 是否 是针对自己上一个包的消息
协议规定:建立桥梁时,双方都要建立通往对方的桥梁
拆除桥梁时,双方都要拆除通往对方的桥梁
建桥时: 3次握手
目标:快速建立双向 双向 双向 通路
所以将 中间的两次信息 合并成 一次
合并成的一条信息后:确认信息 紧跟着 请求信息
通过合并,减少 了 原本这两次信息的时间间隔 ;加快了建立双向数据通路的速度
双方的目标:都是 快速建立双向的数据通路,所以合并两次为一次 是双方事先约定的;即 都是事先就是知道的
只有建桥相关的请求、确认;双方都没有实际数据的传输,不影响双方应用程序的数据传输
所以可以合成3次
拆桥时: 4次挥手
另外一个桥上可能还有数据在传输,不能一起发送请求和确认,需要分成两次发送
所以 总共需要4次发信息
从自己,拆一个方向的桥,说明自己没有信息要传输;而此时从对方到自己的桥可能还有数据在传输
所以,不能合并中间的那两条
需要对方数据发送完之后,由它自己主动发出请求断开的请求...
建桥需3次握手,拆桥需4次挥手的原因:
建立两个单向桥 的过程中,没有进行实际 数据的传输,
所以 答复 和 请求 的顺序没有要求,发送的这两次信息,可以合并成一次发送
拆除这两个单向桥的过程中,一方单向数据传输完毕,这条桥可以立马发出信号请求删除
而另一个单向桥上大多情况下尚有数据在传输,所以需要等其数据传输完毕,由发送方主动提出拆除已方桥梁的拆除
所以是有顺序要求的,因此不能将这两次合并称一次
-----------------------------------------------------
建桥-----通俗版
背景:A区和B区之间交通不太好,需要修高速公路(都是单向的)
①A区:我是A区,我想要修一条到B区的(单向)高速公路,可以吗?
②B区:1.我知道了,你修吧! 2.我是B区,我也想修一条到A区的(单向)高速公路,可以吗?
③A区:我知道了,你修吧!
拆桥-----通俗版
背景:A区和B区中间要建立开发区了,需要拆除高速公路(双向的双车道)
①A区:我是A区 我高速公路上的车辆都清空了,我要拆高速公路了(从我这边驶出的高速公路)
②B区:好的,你拆吧!; 我这边的高速公路(从我这边驶出的高速公路)还没清空车辆
③B区:我是B区,我这边的高速公路上的车辆也清空了,我要拆我这边的高速公路了
⑤A区:好的,你拆吧!
-----------------------------------------------------
服务器所处的状态:
建桥涉及的状态:
LISTEN: 处于监听状态
接收到发送完之后,状态立马 发生改变
SYN_RCVD: 接收到 客户端 的SYN信号;此时(从半连接池 中取出请求,为其进行服务)对SYN请求作出回复
ESTABLISHED: 收到对方的确认信息,立即建出从自己通往对方方向的桥梁
断桥涉及的状态:
FIN_WAIT_1: (数据传输完毕后),拆桥请求已发出
FIN_WAIT_2: s 到 c 的桥已经断开
TIME_WAIT: 一方的数据还没从对方的桥梁接收完,等数据接收完之后,才向对方发送确认信息(此时可以拆除桥梁)
服务器中有个半连接池
半连接池:将很多请求放在里面等待
服务器依次取出 ,取出之后(注意是取出之后)为其进行服务
tcp协议(也叫 好人协议,因为有求必应)
收到答复后,会立刻(几乎没有延时)建立or拆除从当前方向的桥
答复,即 确认信息
SYN洪水攻击
客户端 在发出一个请求后 立马消失
服务端 回应并请求 之后 没有收到 回复,
会隔几秒 重新进行回应并请求; 占用着 服务端的 操作系统资源
从而实现对服务器的攻击
tcp可靠原因:发送端每发一个信息,如果没有收到 接收端的确认信息(告诉发送者 收到了这次的包)
如果发送端没收到该次包的确认信息,则重新再发一次...
鉴于此:发送过的信息保留一段时间.服务端的信息 发送完之后,不会立马删(以备 重新再发一次的情况)
2、udp:
发送过的信息,立马删除
不需要接收方的确认信息,丢了也不会重新再发一次
总结:
upd 相较与 tcp不可靠在于
发送过的信息,立马删除
不需要接收方的确认信息,丢了也不会重新再发一次
==============================> 上网流程 <==========================
1、储备知识
url地址:
http://www.cnblogs.com:80/linhaifeng/articles/6817679.html
三部分组成:
http://
ip地址:80
/linhaifeng/articles/6817679.html
找文件要通过 文件路径,同理,找服务器上的文件 也要通过路径
默认端口号:80
注意https方式不可通过端口进行访问
http方式可以
url:统一资源定位符
url
http://ip:端口号/文件(资源)路径
可以标志世界上唯一的一份文件
2、上网流程
填写url ①通信协议:http、ftp等 ②域名 ③端口号(不写则使用默认值80) ④文件路径
查询DNS系统,由服务器的域名 得到 其ip(定位到目标主机)
通过端口,指定要访问的应用程序
在域名后面指明文件路径,得到路径