UDP 和 TCP 的 socket 分别一般用在什么地方_百度知道
UDP 和 TCP 的 socket 分别一般用在什么地方
他们传输的只是一条命令和参数、需要确保数据的完整时可以用。一般FTP HTTP什么的都是使用TCP。UDP用于少量数据的传输，时间和空间开销相对较小，数据少，不分片，但是时间和空间开销大，在有的RIP中自己定义了重传的机制。而一般的RIP协议都是用UDP封装的TCP用于大批量数据的传输，而且为保证数据的可靠到达。RIP往往可能传输一次就完成，他们要么是数据量大或是保证数据完整
采纳率：54%
为您推荐：
其他类似问题
udp的相关知识
等待您来回答Posts - 82,
Articles - 4,
Comments - 20
记录和总结web开发技术的点点滴滴...
17:15 by wish123, ... 阅读,
提醒：貌似这里说的socket是指port，而非socket api技术！仅供参考！貌似标题命名不准确的说
《更安全的Linux网络》第1章防火墙的基本概念，在本书的开始将详尽讲解与防火墙相关的TCP/IP技术。此外，对于防火墙的原理、种类、架构及其优、缺点，在本章中也都有详尽的介绍。本节为大家介绍TCP、UDP及Socket的关系。
1.4 TCP、UDP及Socket的关系
在了解了信息在网络上是如何传递之后，接下来，我们要认识传输层中另一个重要的标记&&Port。Port在传输层中是一个很重要的概念，我们之所以能够在一台主机上同时执行多个服务，都得归功于Port的概念。在开始谈Port之前，我们先来了解什么是Socket。
Socket是指一个上面有很多&洞&的东西，比如说，计算机主机板上CPU的插座，我们称其为Socket 478或Socket
939等，而Socket上面这些洞在传输层中则称为Port，在OS的网络系统中会有两个Socket，分别为TCPSocket及UDP
Socket，Socket上各有65536个洞，我们把它称为Port 0、Port 1、Port 2 && Port 65 535。
我们以图1-11为例来说明Port的用途，图的左边为Client端、图的右边则为Server端，在Server端主机上，我们假设执行了Web、
SSH及DNS这3项服务，在 TCP/IP的网络规范中，每一个网络应用程序执行时都会占用一个Port，如Server端的Web
Service启动时，就会占用在TCP Socket中的Port80，简称为TCP Port 80，而SSH Service是TCP Port
22、DNS Service则为UDP Port 53，因此我们可以说，TCP Port 80代表Web Service程序，TCPPort
22代表SSH Service程序，而UDP Port 53即代表DNS Service程序。
图1-11&&TCP、UDP及Port的关系
另外，在Client部分，我们假设Client端启动了Browser、SSH Client及DNS Client
这3个网络应用程序，在TCP/IP的规范中，客户端的网络应用程序启动时，一样也会占用一个Port。如图1-11所示，我们假设Browser使用
TCP Port 2099、SSH Client使用TCP Port 2088，以及DNS Client使用UDPPort
5555，因此，我们也可以说，TCP Port 2099代表Browser程序、TCPPort 2088代表SSH Client程序、而UDP
Port 5555则代表DNS Client程序。接下来看Port的用途。假设Client端主机上的Browser欲与Server端的Web
Service 来传递数据，因此，Client端主机随即产生一个数据封包送至 Server 端。我们假设 Client 端的 IP 为
10.0.1.219、Server 端的 IP
为202.43.195.52，这个封包的内容就如图1-12所示。首先，封包内必然会记录封包的来源及目的，在图1-12中所标记的部分即为封包的来源
及目的地址，但光是这两项信息只能代表Client端及Server端在传送数据，并无法说明Client端主机上哪一个应用程序在访问，所标记的部分就
说明了Client端以Port 2099来连接Server端的Port
80，但别忘了刚才说过的，Port可以代表主机上目前正在执行的某一个应用程序。
图1-12&&Client送至Server的封包内容
从以上说明我们可以了解，系统在接到一个封包之后，它是如何来辨别这个数据封包是要送给哪一个应用程序的。
当Web Service接到这个请求封包之后，Web
Service也会回应Client端主机一个封包，而这个封包的内容就如图1-13所示，图中③所标记的位置为来源及接收端主机的IP，标记④的位置则
表示来源端的Web Service（Port 80）及响应给Client端主机的浏览器（Port
2099）。由以上例子相信你已经了解了Port的用途。
图1-13&&Server回应Client的封包内容
在了解Port的用途之后，我们要了解65536个Port是如何被分配使用的。其实，不管是TCP Port或UDP Port的运用，在RFC 1700文档中都有完整的规范，我们可以从IANA的网站（）中取得Port的使用列表，或是从Linux系统中的/etc/services文件中取得这些信息，笔者将其整理如下。
公认的Port：0～1023。
注册的Port：。
动态的Port：49 152～65 535。
1. 公认的Port
会使用TCP Port 80，因为它是一个&规范&、是大家都知道的事，所以Client端在Web Server上访问Web
Service时，Client端就会预设将封包送至Web Server的TCP Port
80。也因为有规范的存在，所以我们要访问远程的某个服务时，就无须特别打电话去询问：&你们家的Web
Service是使用在哪个Port中&，换句话说，每个Service都会有一个固定的Port，而这些Port我们就称为公认的Port，其范围为
2. 注册的Port
由于在同一时间内，相同的Port只能给一个程序使用，因此，程序设计师在编写网络应用程序时，就得特别注意自己开发的应用程序是使用哪一个Port，而
这个Port是否已经被其他的应用程序占用了，但问题是程序设计师如何得知该Port已被其他应用程序占用了呢？所幸的是IANA组织定了一个规范，为了
避免不必要的Port冲突，在指定Port之前，凡是需要用到固定Port的网络应用程序可先在IANA的网站上选用一个没有其他应用程序在使用的
Port，并且可以将其注册下来，以告诉其他的程序设计师，某个Port已被你所选用且已被注册，通过IANA机制即可避免Port冲突的问题，而这些可
被使用者注册的Port范围为。
3. 动态的Port
动态的Port通常应用在暂时性的使用上，例如，几乎所有Client端的应用程序都会使用动态Port，在Client端的应用程序启动时，系统就会分
配一个&动态的Port&给该应用程序使用，并且在应用程序结束时将Port归还给系统，而这些动态的Port范围为49 152~65 535。
请注意，以上所讲的&规范&并非所有程序设计师都会遵循，比如说，Linux系统上的SSH
Client所使用的Port通常都会落在&注册的Port&范围内，其实这并不会对系统造成什么问题。原则上，&相同一个Port在同一时间内不得有一
个以上的应用程序同时使用&，只要把握这个原则，基本上都是可以被接受的。22071人阅读
Windows（13）
计算机网络（15）
&&& 为了区分不同应用进程间的网络通信和连接，主要有3个参数：通信的目的IP地址、使用的传输层协议(TCP 或 UDP)和使用的端口号。
&&& Socket的原意是“插座”。通过将这3个参数结合起来，与一个“插座”Socket绑定，应用层就可以和传输层通过套接字接口，区分来自不同应用程序进程或网络连接的通信，实现数据传输的并发服务。
&&& accept()产生的Socket端口号是多少？
&&& 要写网络程序就必须用Socket，这是程序员都知道的。而且，面试的时候，我们也会问对方会不会Socket编程？一般来说，很多人都会说，Socket编程基本就是listen, accept, 以及send, write等几个基本的操作。是的，就跟常见的文件操作一样，只要写过就一定知道。
&&& 对于网络编程，我们也言必称TCP/IP，似乎其他网络协议已经不存在了。对于TCP/IP，我们还知道TCP和UDP，前者可以保证数据的正确和可靠性，后者则允许数据丢失。最后，我们还知道，在建立连接前，必须知道对方的IP地址和端口号。除此，普通的程序员就不会知道太多了，很多时候这些知识已经够用了。最多，写服务程序的时候，会使用多线程来处理并发访问。
我们还知道如下几个事实：
1. 一个指定的端口号不能被多个应用程序共用。比如，如果IIS占用了80端口，那么Apache就不能也用80端口了；
2. 很多防火墙只允许特定目标端口的数据包通过。
3. 服务程序在listen某个端口并accept某个连接请求后，会生成一个新的socket来对请求进行处理。
&&& 于是，一个困惑了我很久的问题就产生了，如果一个socket创建后并与80端口绑定后，是否就意味着该socket占用了80端口呢？
&&& 如果是这样的，那么当其accept一个请求后，生成的新的socket到底使用的是什么端口呢(我一直以为系统会默认给其分配一个空闲的端口号)？
&&& 如果是一个空闲的端口，那么一定不是80端口了，于是以后的TCP数据包的目标端口就不是80了——防火墙一定会阻止其通过的！
&&& 实际上，我们可以看到，防火墙并没有阻止这样的连接，而且这是最常见的连接请求和处理方式。我不理解的就是，为什么防火墙没有阻止这样的连接？它是如何判断那条连接是因为connect80端口而生成的？是不是TCP数据包里有什么特别的标志？或者防火墙记住了什么东西？
&&&&&&后来，我又仔细研读了TCP/IP的协议栈原理，对很多概念有了更深刻的认识。比如，TCP和UDP同属传输层，共同架设在IP层(网络层)之上。而IP层主要负责的是在节点之间(End to End)的数据包传送，这里的节点是一台网络设备，比如计算机。因为IP层只负责把数据送到节点上，而不能区分上面的不同应用，所以TCP和UDP协议在其基础上加入了端口的信息，端口于是标识的是一个节点上的一个应用。除了增加端口信息，UDP协议基本就没有对IP层的数据进行任何处理了。而TCP协议还加入了更复杂的传输控制，比如滑动的数据发送窗口(Slice
Window)，以及接收确认和重发机制，以达到数据的可靠传送。不管应用层看到的是怎样一个稳定的TCP数据流，下面传送的都是一个个的IP数据包，需要由TCP协议来进行数据重组。
&&&&&& 所以，我有理由怀疑，防火墙并没有足够的信息判断TCP数据包的更多信息，除了IP地址和端口号。而且，我们也看到，所谓的端口，是为了区分不同的应用的，以在不同的IP包来到的时候能够正确转发。
&&&&&&TCP/IP只是一个协议栈，就像操作系统的运行机制一样，必须要具体实现，同时还要提供对外的操作接口。就像操作系统会提供标准的编程接口，比如Win32编程接口一样，TCP/IP也必须对外提供编程接口，这就是Socket编程接口——原来是这么回事啊！
&&&&&&在Socket编程接口里，设计者提出了一个很重要的概念，那就是socket。这个socket跟文件句柄很相似，实际上，在BSD系统里就是跟文件句柄一样存放在一样的进程句柄里。这个socket其实是一个序号，表示其在句柄表中的位置。这一点，我们已经见过很多了，比如文件句柄，窗口句柄等。这些句柄，其实是代表了系统中的某些特定的对象，用于在各种函数中作为参数传入，以对特定对象进行操作——这其实是C语言的问题，在C++语言里，这个句柄其实就是this指针，实际就是对象指针啦。
现在我们知道，socket跟TCP/IP并没有必然的联系。Socket编程接口在设计的时候，就希望也能适应其他的网络协议。所以，socket的出现只是可以更方便的使用TCP/IP协议栈而已，其对TCP/IP进行了抽象，形成了几个最基本的函数接口。比如create, listen, accept, connect, read和write等。
现在我们明白，如果一个程序创建了一个socket，并让其监听80端口，其实是向TCP/IP协议栈声明了其对80端口的占有。以后，所有目标是80端口的TCP数据包都会转发给该程序(这里的程序，因为使用的是Socket编程接口，所以首先由Socekt层来处理)。所谓的accept函数，其实抽象的是TCP的连接建立过程。accept函数返回的新socket其实指代的是本次创建的连接，而一个连接是包括两部分信息的，一个是源IP和源端口，另一个宿IP和宿端口。这样的话，这些socket宿端口就可以都是80！而同时，防火墙的对IP包的处理规则也是清晰明了，不存在前面设想的种种复杂的情形。
&&&&&&明白socket只是对TCP/IP协议栈操作的抽象，而不是简单的映射关系，这很重要！
昨天和朋友聊了下网络编程，关于Socket，这里写一下我个人的一些理解:)
程序里可以创建Socket，分为普通Socket和原始Socket两种类型。
一：普通Socket是对TCP/IP协议栈中传输层的操作的编程接口(一种API)。
有面向连接的流式套接字(SOCK_STREAM)，属于针对TCP方式的应用；
有无连接数据包式套接字(SOCK_DGRAM)，属于针对UDP方式的应用。
&&&&&&对于普通Socket，我曾经有个模糊的问题，在多线程情况下，服务器端监听(listen)某个端口(假设8080)后，每accept一个客户端的连接就会产生一个新的Socket。那么这些新产生的Socket的端口是什么？程序里肯定没有指定，那就应该有两种可能，1：产生随机端口。2：还是8080端口。第一种假设想了就觉得不可能，防火墙非常有可能会阻止这些随机端口的包。那么就是第二种假设了，服务端端口还是8080。但这推翻了我原有的认识，就是“一个端口被程序占有，其他程序就不能用该端口了”。我觉得其实最有可能的是范围不同：就是在程序与程序间不能用同一端口，但是在程序内部不同的Socket还是可以用同一端口的。所以，为了能够使“客户端发给服务端的同一端口(8080)不同线程(即不同的Socket连接)的包能够被区分开并进行组合”，必须得有一个区分包是来自不同连接的显著特征，那就是传输层包头里的源端口了，即一个Socket连接里客户端那方的端口。总结一下，对于这种情况，就是传输层包头里源端口(客户端)会随着产生的Socket不同，而宿端口相同(服务器端)。
二：原始Socket，建立在网络层上，所以我们可以在传输层上构建自己的协议。
如果是自己做个Sniffer(网络嗅探器)，那么监听到的包是来自同一网段的普通Socket包(TCP方式或UDP方式)，所以在程序里我们要自己写数据结构(IP头和TCP或UDP头)，并绑定数据。
如果是客户端和服务端都是由自己用原始Socket写的，那么可以自己控制协议，像一些网络应用(MSN, skype等)，可以在网络层往上重写协议。
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：1727371次
积分：15351
积分：15351
排名：第595名
原创：210篇
转载：19篇
评论：586条
左手代码右手艺术 追求新浪潮。
个人网站：
: Unity3D内购插件
: Unity3D常用功能合集
微信公众号：松阳论道
我写的书：
阅读：3135
文章：18篇
阅读：51018
阅读：116947
文章：18篇
阅读：561803
文章：15篇
阅读：120972
(10)(1)(1)(1)(2)(1)(3)(1)(3)(1)(3)(1)(4)(1)(5)(5)(6)(4)(1)(1)(3)(1)(1)(1)(2)(6)(8)(1)(4)(2)(7)(10)(7)(3)(3)(1)(3)(1)(4)(11)(15)(21)(27)(29)(1)(3)你正在使用的浏览器版本过低，将不能正常浏览和使用知乎。