8-12-传输层协议:tcp与upd、url(全球资源定位符)

今日内容:
    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(定位到目标主机)
	通过端口,指定要访问的应用程序
	在域名后面指明文件路径,得到路径
  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值