徽标
联盟百科
通讯
下载应用,请到 Google Play
新! 在您的Android™设备上下载联盟百科!
下载
比浏览器更快的访问!
 

互联网和传输控制协议

快捷方式: 差异相似杰卡德相似系数参考

互联网和传输控制协议之间的区别

互联网 vs. 传输控制协议

互联网(Internet),是網路與網路之間所串連成的龐大網路,這些網路以一組標準的網路TCP/IP协议族相連,連接全世界幾十億個設備,形成邏輯上的單一巨大國際網络。,它是由從地方到全球範圍內幾百萬個私人的、學術界的、企業的和政府的網络所構成,通過電子,無線和光纖網絡技術等等一系列廣泛的技術聯繫在一起。这种将计算机网络互相联接在一起的方法可称作「网络互联」,在這基础上发展出覆蓋全世界的全球性互联網絡稱互聯網,即是互相連接一起的网络。互聯網並不等同万维网(WWW),万维网只是一個基於超文本相互鏈接而成的全球性系統,且是互聯網所能提供的服務其中之一。互聯網帶有範圍廣泛的信息資源和服務,例如相互關聯的超文本文件,还有萬維網的應用,支持電子郵件的基礎設施,對等網絡,文件共享,以及IP電話服務。. 传输控制协议(Transmission Control Protocol,縮寫為TCP)是一种面向连接的、可靠的、基于字节流的传输层通信协议,由IETF的RFC 793定义。在简化的计算机网络OSI模型中,它完成第四层传输层所指定的功能,用户数据包协议(UDP)是同一层内另一个重要的传输协议。 在因特网协议族(Internet protocol suite)中,TCP层是位于IP层之上,应用层之下的中间层。不同主机的应用层之间经常需要可靠的、像管道一样的连接,但是IP层不提供这样的流机制,而是提供不可靠的包交换。 应用层向TCP层发送用于网间传输的、用8位字节表示的数据流,然后TCP把数据流分割成适当长度的报文段(通常受该计算机连接的网络的数据链路层的最大传输单元(MTU)的限制)。之后TCP把结果包传给IP层,由它来通过网络将包传送给接收端实体的TCP层。TCP为了保证不发生丢包,就给每个包一个序号,同时序号也保证了传送到接收端实体的包的按序接收。然后接收端实体对已成功收到的包发回一个相应的确认(ACK);如果发送端实体在合理的往返时延(RTT)内未收到确认,那么对应的数据包就被假设为已丢失将会被进行重传。TCP用一个校验和函数来检验数据是否有错误;在发送和接收时都要计算校验和。.

之间互联网和传输控制协议相似

互联网和传输控制协议有(在联盟百科)5共同点: 简单邮件传输协议网际协议用户数据报协议超文本传输协议Telnet

简单邮件传输协议

单邮件传输协议 (Simple Mail Transfer Protocol, SMTP) 是事实上的在Internet传输email的标准。 SMTP是一个相对简单的基于文本的协议。在其之上指定了一条消息的一个或多个接收者(在大多数情况下被确认是存在的),然后消息文本会被传输。可以很简单地通过telnet程序来测试一个SMTP服务器。SMTP使用TCP端口25。要为一个给定的域名决定一个SMTP服务器,需要使用MX (Mail eXchange) DNS。 在八十年代早期SMTP开始被广泛地使用。当时,它只是作为UUCP的补充,UUCP更适合于处理在间歇连接的机器间传送邮件。相反,SMTP在发送和接收的机器在持續連線的网络情况下工作得最好。 Sendmail是最早使用SMTP的邮件传输代理之一。到2001年至少有50个程序将SMTP实现为一个客户端(消息的发送者)或一个服务器(消息的接收者)。一些其他的流行的SMTP服务器程序包括了Philip Hazel的exim,IBM的Postfix, D. J. Bernstein的Qmail,以及Microsoft Exchange Server。 由于这个协议开始是基于纯ASCII文本的,它在二进制文件上处理得并不好。诸如MIME的标准被开发来编码二进制文件以使其通过SMTP来传输。今天,大多数SMTP服务器都支持8位MIME扩展,它使二进制文件的传输变得几乎和纯文本一样简单。 SMTP是一个“推”的协议,它不允许根据需要从远程服务器上“拉”来消息。要做到这点,邮件客户端必须使用POP3或IMAP。另一个SMTP服务器可以使用ETRN在SMTP上触发一个发送。.

互联网和简单邮件传输协议 · 传输控制协议和简单邮件传输协议 · 查看更多 »

网际协议

網際協議(Internet Protocol,縮寫為IP),又译互联网协议,是用于封包交換数据网络的一种协议。 IP是在TCP/IP协议族中网络层的主要协议,任务仅仅是根据源主机和目的主机的地址来传送数据。为此目的,IP定义了寻址方法和数据报的封装结构。第一个架构的主要版本,现在称为IPv4,仍然是最主要的互联网协议,尽管世界各地正在积极部署IPv6。.

互联网和网际协议 · 传输控制协议和网际协议 · 查看更多 »

用户数据报协议

户数据报协议(User Datagram Protocol,縮寫為UDP),又稱使用者資料包協定,是一个简单的面向数据报的传输层协议,正式規範為RFC 768。 在TCP/IP模型中,UDP为网络层以上和应用层以下提供了一个简单的接口。UDP只提供数据的不可靠传递,它一旦把应用程序发给网络层的数据发送出去,就不保留数据备份(所以UDP有时候也被认为是不可靠的数据报协议)。UDP在IP数据报的头部仅仅加入了复用和数据校验(字段)。 UDP首部字段由4个部分组成,其中两个是可选的。各16bit的來源端口和目的端口用来标记发送和接受的应用进程。因为UDP不需要应答,所以來源端口是可选的,如果來源端口不用,那么置为零。在目的端口后面是长度固定的以字节为单位的长度域,用来指定UDP数据报包括数据部分的长度,长度最小值为8byte。首部剩下地16bit是用来对首部和数据部分一起做校驗和(Checksum)的,这部分是可选的,但在实际应用中一般都使用这一功能。 由于缺乏可靠性且屬於非連接導向協定,UDP应用一般必须允许一定量的丢包、出错和复制貼上。但有些应用,比如TFTP,如果需要则必须在应用层增加根本的可靠机制。但是绝大多数UDP应用都不需要可靠机制,甚至可能因为引入可靠机制而降低性能。流媒體(串流技術)、即时多媒体游戏和IP电话(VoIP)一定就是典型的UDP应用。如果某个应用需要很高的可靠性,那么可以用传输控制协议(TCP协议)来代替UDP。 由于缺乏拥塞控制(congestion control),需要基于网络的机制来减少因失控和高速UDP流量负荷而导致的拥塞崩溃效应。换句话说,因为UDP发送者不能够检测拥塞,所以像使用包队列和丢弃技术的路由器这样的网络基本设备往往就成为降低UDP过大通信量的有效工具。数据报拥塞控制协议(DCCP)设计成通过在诸如流媒体类型的高速率UDP流中,增加主机拥塞控制,来减小这个潜在的问题。 典型网络上的众多使用UDP协议的关键应用一定程度上是相似的。这些应用包括域名系统(DNS)、简单网络管理协议(SNMP)、动态主机配置协议(DHCP)、路由信息协议(RIP)和某些影音串流服務等等。.

互联网和用户数据报协议 · 传输控制协议和用户数据报协议 · 查看更多 »

超文本传输协议

超文本傳輸協定(英文:HyperText Transfer Protocol,縮寫:HTTP)是一種用於分佈式、協作式和超媒體信息系統的應用層協議。HTTP是全球資訊網的數據通信的基礎。 设计HTTP最初的目的是为了提供一种发布和接收HTML页面的方法。通过HTTP或者HTTPS协议请求的资源由统一资源标识符(Uniform Resource Identifiers,URI)来标识。 HTTP的发展是由提姆·柏內茲-李於1989年在歐洲核子研究組織(CERN)所發起。HTTP的標準制定由万维网协会(World Wide Web Consortium,W3C)和互联网工程任务组(Internet Engineering Task Force,IETF)進行協調,最终发布了一系列的RFC,其中最著名的是1999年6月公佈的 RFC 2616,定義了HTTP協議中現今廣泛使用的一個版本——HTTP 1.1。 2014年12月,互联网工程任务组(IETF)的Hypertext Transfer Protocol Bis(httpbis)工作小组将HTTP/2标准提议递交至IESG进行讨论,于2015年2月17日被批准。 HTTP/2标准于2015年5月以RFC 7540正式发表,取代HTTP 1.1成为HTTP的实现标准。.

互联网和超文本传输协议 · 传输控制协议和超文本传输协议 · 查看更多 »

Telnet

Telnet協議是一種應用層協議,使用於網際網路及區域網中,使用虛擬終端機的形式,提供雙向、以文字字串為主的命令列介面互動功能。屬於TCP/IP協議族的其中之一,是Internet遠端登錄服務的標準協議和主要方式,常用於伺服器的遠端控制,可供使用者在本地主機執行遠端主機上的工作。 Telnet在1969年開發出來,在 RFC 15 定義, RFC 854 定義了擴充功能。互联网工程任务组(IETF),在中,將其加以標準化,是最早形成的網際網路協議之一。.

Telnet和互联网 · Telnet和传输控制协议 · 查看更多 »

上面的列表回答下列问题

互联网和传输控制协议之间的比较

互联网有137个关系,而传输控制协议有45个。由于它们的共同之处5,杰卡德指数为2.75% = 5 / (137 + 45)。

参考

本文介绍互联网和传输控制协议之间的关系。要访问该信息提取每篇文章,请访问:

嘿!我们在Facebook上吧! »