计网笔记

TCP UDP
TPC运输单元:segment
UDP运输单元:datagram
TCP
(面向连接的,可靠的,要增加额外的开销:确认、流量控制、计时器、连接管理)
1.面向连接,使用前后要分别建立、释放(TCP的端口称为socket = ip地址:(运输层协议)端口号)
2.可靠交付
3.面向字节流(不关心发送到TCP缓存的报文长度,由对方的窗口值和网络拥塞程度决定)
3.仅支持点对点
4.全双工
UDP
1.无连接(不需要socket)
2.尽最大努力交付(不可靠)
3.面向报文(报文长度由应用进程给出)
4.没有拥塞控制
5.支持...多对多的通信
6.首部开销小 (8byte,源/目的端口,长度,检验和,每个均16位)

Q.视频/游戏使用那种协议?

Q.实现简单的可靠传输
1.停止等待协议
当出现差错时实现超时重传->发送方为每一个发送分组设置超时计数器,接收到接收方的返回则撤销(发送后保留副本、编号)
超时(不知道是出错还是丢失还是确认丢失)则重传分组,接受方丢弃该重复分组并向发送方发送确认
没有确认丢失,但确认迟到的情况下接收方直接丢弃收到的确认迟到

该可靠传输协议常称为自动重传请求ARQ

2.连续自动重传请求协议
累积确认:接收方对按序到达最后一个分组发送确认
如果滑动窗口共5个分组,第3个丢失了,后面4 5不管是否到达都要回退到3
其他细节有点疑问,暂留

... / seq / ack / ... / ACK / ... / SYN /...

ACK=1时ack有效
SYN=1&&ACK=0表示为一个连接请求报文段
SYN=1&&ACK=1表示为同意建立连接
SYN=1时不能携带数据
Q.if SYN=0?
此时是确认报文段,是否有效看ACK

Q.TCP的可靠传输实现
1.字节单位的滑动窗口
A的发送窗口(由B的确认报文段决定):没有收到B确认时可以把窗口内的数据发送出去
B的接收窗口:B只能对按序收到的数据中的最高序号给出确认(哪怕后面的乱序序号也接收到)
接收窗口中的未按序到达数据则暂存
细节:
接受窗口一旦首部和相连的后续数据接收到则前沿右移,并发送确认,另一方发送窗口P1右移,P2不变,P3由窗口字段决定
P2=P3只是不能发送新数据,超时重传窗口内(大于等于P1)的数据是允许的!
Q.缓存的大小?

Q.A发送数据给B,B返回的rwnd决定A的发送窗口大小,那接收窗口怎么决定?

Q.流量控制
1.滑动窗口
通过rwnd的大小(由缓存决定)来控制流量速率
死锁:当B发送rwnd=0后发现缓存已有空间剩余,重新发送rwnd=x后却丢失了,A无法接收(Q.为什么B不重传?)
TCP为每一个连接设置持续计数器,当一方收到rwnd=0时则启动,到期则发送1byte的零窗口探测报文段
2.效率
Nagle算法

Q.拥塞控制
1.慢开始
2.拥塞避免
3.快重传
4.快恢复

Q.运输连接管理
C/S模式,C=A,S=B
1.三次握手
第一次握手:

B创建TCB,服务器进程处于LISTEN状态;
A的TCP客户进程创建TCB,向B发送**连接请求**报文段(SYN=1且消耗一个seq=x),进程处于SYN-SENT

第二次握手:

B收到若**同意建立**则向A发送**确认**(SYN=1&&ACK=1,ack=x+1,seq=y,注意双方seq没必然联系),进程处于SYNC-RCVD

第三次握手

A的进程收到B确认,再向B给出**确认**(ACK=1,seq=x+1,ack=y+1),ACK报文段可携带数据,如果不携带则不消耗序号(也就是说seq用不着,下一个还是x+1,这里采用携带数据的方式),双方进程处于ESTAB-LISHED

细节:
存在四次握手的方式,也就是第二次握手B先确认(ACK=1,ack=x+1)再发送同步(SYN=1,seq=y),效果一致
两次确认:防止失效连接请求重传(B认为是建立新的连接,而A不作回应,B会一直等待数据,所以要再次确认,若A没有确认,则得知是异常)

2.四次挥手
第一次挥手:

A发送连接释放报文段(FIN=1,seq=u),主动关闭,处于FIN-WAIT-1

第二次挥手:

B收到后发出**确认**(ACK=1,seq=v,ack=u+1)

复用:应用层app可通过运输层再传送到网络层
分用:运输层从IP层收到发送到各App的数据后,必须分别交付指明的各应用进程

两个计算机的进程通信:IP/port
常用port:80/http、443/https、21/ftp、25/smtp、53/dns

last update:19/03/31

标签: none

添加新评论