计算你网络及因特网.pptVIP

求职应注意的礼仪 求职时最礼貌的修饰是淡妆 面试时最关键的神情是郑重 无论站还是坐，不能摇动和抖动 对话时目光不能游弋不定 要控制小动作 不要为掩饰紧张情绪而散淡 最优雅的礼仪修养是体现自然 以一种修养面对两种结果 必须首先学会面对的一种结果被拒绝 仍然感谢这次机会，因为被拒绝是面试后的两种结果之一。 被拒绝是招聘单位对我们综合考虑的结果，因为我们最关心的是自己什么地方与用人要求不一致，而不仅仅是面试中的表现。 不要欺骗自己，说“我本来就不想去”等等。 认真考虑是否有必要再做努力。 必须学会欣然面对的一种结果被接纳 以具体的形式感谢招聘单位的接纳，如邮件、短信 考虑怎样使自己的知识能力更适应工作需要 把走进工作岗位当作职业生涯的重要的第一步，认真思考如何为以后的发展开好头。 Thank you * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * Kurose and Ross forgot to say anything about wrapping the carry and adding it to low order bit * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 运输层 * UDP: 用户数据报协议 [RFC 768] “没有不必要的,” “基本要素” 互联网传输协议 “尽力而为”服务，UDP段可能： 丢包 对应用程序交付失序 无连接: 在UDP发送方和接收方之间无握手 每个UDP段的处理独立于其他段 为何要有 UDP协议? 不建立连接 它将增加时延 简单：在发送方、接收方无连接状态 段首部小 无拥塞控制: UDP能够尽可能快地传输 运输层 * UDP: 其他 常用于流式多媒体应用 丢包容忍 速率敏感 其他UDP应用 DNS SNMP 经UDP的可靠传输 : 在应用层增加可靠性 应用程序特定的差错恢复！ 源端口# 目的端口# 32 bits 应用数据 报文 UDP 段格式 长度 检查和 UDP段的长度，包括首部，以字节计 运输层 * UDP检查和 发送方: 将段内容处理为16比特整数序列 检查和: 段内容的加法 反码和 发送方将检查和放入UDP检查和字段 接收方: 计算接收的段的检查和 核对计算的检查和是否等于检查和字段的值: NO – 检测到差错 YES – 无差错检测到。虽然如此，还可能有差错吗？详情见后…… 目的: 在传输的段中检测“差错” 如比特翻转 运输层 * 互联网检查和例子 注意 当数字作加法时，最高位进比特位的进位需要加到结果中 例子: 两个16-bit整数相加 1 1 1 1 0 0 1 1 0 0 1 1 0 0 1 1 0 1 1 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 1 1 1 0 1 1 1 0 1 1 1 0 1 1 1 1 0 0 取反码 1 0 1 0 0 0 1 0 0 0 1 0 0 0 0 1 1 回卷 和 检查和 1 0 0 1 1 0 0 1 1 0 0 1 1 0 1 1 1 0 1 0 0 1 0 1 0 1 0 1 0 1 0 1 练习 运输层 * TCP概述 RFCs: 793, 1122, 1323, 2018, 2581 全双工数据: 同一连接上的双向数据流 MSS: 最大报文段长度 MTU:最大传输单元 面向连接: 在进行数据交换前，初始化发送方与接收方状态，进行握手 交换控制信息 , 流量控制: 发送方不能淹没接收方 拥塞控制: 抑止发送方速率来防止过分占用网络资源 点到点: 一个发送方, 一个接收方 连接状态与端系统有关，不为路由器所知 可靠、有序的字节流: 没有 “报文边界” 流水线: TCP拥塞和流量控制设置滑动窗口协议 发送和接收缓冲区 运输层 * TCP 报文段结构 源端口 # 目的端口 # 32 bits 应用层数据 变长 序号 确认号 接收窗口 紧急数据指针 检查和 F S R P A U 首部 长度 未 用 选项 变长 URG: 紧急数据 一般不用 ACK: ACK 序号 有效 PSH: 立即提交数据 一般不用 RST, SYN, FIN: 连接建立