11

IANA has reserved both TCP and UDP port 0. See the IANA Service Name and Transport Protocol Port Number Registry. IANA is the Internet Assigned Numbers Authority, so all internet numbers, including port numbers, are assigned by IANA. OSes have reserved that port number for an application to request an ephemeral port number by using it as a source port number,...


9

TL;DR: RFC870 Port zero has been included in the "Network Wide Standard Functions" range since RFC433 in 1972, but has never been assigned. https://www.rfc-editor.org/rfc/rfc433.html Here the range is given as 0-63, but the first assignment is port 1. I can find no "Assigned Numbers" RFC which assigns port 0. In October 1983, for the ...


8

You are confusing a couple of things. MTU is Maximum Transmission Unit, and it is a value of the data-link (layer-2) protocol on a specific medium. IP, neither IPv4 nor IPv6 has an MTU. They both have maximum packet sizes, which are much larger than any data-link MTU. The total packet size (header and payload) for an IPv4 packet is 65,535 octets. For IPv6, ...


7

Realtime applications don't care so much about in-order reception as about in-time delivery = low latency. Roughly speaking, there is only a defined, small window in time where data is useful. Late data is simply useless. If data is lost you might get a small glitch in video (or audio) but the clip continues to run (=the application is designed to cope with ...


7

Short answer: Multimedia implements protocols on top of UDP. They implement the required functionality. Actually, they have more functionality, and are more complex than TCP. Less short answer: see the answer of @Zac67. Long answer: I hope that the text below will provide you with a better understanding on this issue. Transmitting Multimedia over IP First, ...


4

At a high level, they are equivalent. They are both "Secure Communication" protocols which create a "tunnel" between two end points. Data transferred within this tunnel is protected with Confidentiality, Integrity, and Authentication. In practice, TLS/SSL/DTLS & IPSec (and SSH!) are all considered equally secure as protocols -- it's ...


3

The triple handshake take three single trips between the connection partners A and B: A->B: SYN B->A: SYN+ACK [A is fully synchronized after receiving B's SYN/ACK] A->B: ACK [A can already send data through the socket right after ACKing B's sequence number] A round trip is both ways: A->B->A. Assuming A->B and B->A delays are equal, ...


3

But what if we eliminated this from the protocol. Then it would not be TCP. The point of flow control is that the receiving host has a buffer to receive data, and it is a fixed size. The receiver tells the sender what the available buffer space is left in the acknowledgements. As the receiving TCP receives data and fills the buffer, the window shrinks, and ...


3

That depends on whose definition of socket you use and in some cases whether the packet is opening a new connection or transferring data for an existing connction. The RFC that defines TCP defines the term socket as a combination of an IP address and a port. By this definition the two packets have the same socket on the server side but different sockets on ...


2

They both provide authentication and confidentiality. The difference is TLS is configured by the application. In other words your application needs to be configured to use it. An IPSec VPN, on the other hand, is configured at the network layer and creates a tunnel for the application. The application is unaware that a VPN is being used.


2

It is really guessing based on the source and destination IP addresses and ports, along with the timing. After a period of no traffic between those addresses and ports, it is considered done. Different observers will have their own algorithms to determine when a UDP exchange is closed based on the timing. There is no standard for that because UDP is ...


2

Rather simple: each direction has its own and independent sequence number and sliding window. So, whether the ends are sending data unidirectionally (one end just ACKing with otherwise empty segments) or bidirectionally doesn't matter.


2

IDLE is a PCS code symbol in 100BASE-X (from the 4b/5b set) on the physical layer, see IEEE 802.3 Clause 24 for details. As most of Fast Ethernet's physical layer, it's been borrowed from ANSI X3T12 aka FDDI. IDLEs are continuously sent when there's no data transmission: The Idle code-group (/I/) is transferred between streams. It provides a continuous fill ...


2

You seem to be confusing the congestion window with the receive window. The congestion window is always >=1. The receive window can be 0. The congestion window is controlled and only known by the sender, and the receive window is controlled by the receiver and transmitted to the sender. They are two completely different things. The receive window is ...


2

Assume a sender / server connected to its local network at 10Gbps. Assume 10Gbit/s networking from the sender to the WAN Edge router of it's datacenter. Assume a WAN Edge Router with 10Gbps on the datacenter side and multiple WAN circuits of 100Mbps each. Assume a WAN Router at one of the spoke sites, with 100Mbps WAN and 1Gbps LAN connectivity. Assume the ...


2

I still do not understand the question fully and thus point out where misconception comes from. But, does this clarify things? Note, that TCP is stream based, i.e., on the sender side (left) upper layer passes the stream of bytes which TCP divides into packets. on the receiver TCP reassembles the stream from packets and passes bytes to the upper layer. I ...


2

There is no general rule - some networks pass packets up to the over-standard-Ethernet MTU (1500 bytes), some don't. 508 bytes for UDP payload is derived from the minimum MTU of 576 bytes and looks plausible - but is not efficient. The ideal way to deal with this - for maximum efficiency - is to make your system support variable datagram sizes and use path ...


1

TCP is connection-oriented protocol whereas IP isn't connection-oriented protocol. Correct. Any packets before sending into transport layer sorted operation must have been done in network layer. The transport layer can't get its datagrams/segments anywhere by itself. It requires the routing service done in the network layer. The re-sorting of out-of-order ...


1

You're mixing two different things: VPN as a tunnel provider versus SSL/TLS for application-specific encryption IPsec over TLS/DTLS for other reasons The main point for a VPN is to create a tunneled link where you can pass private traffic in a secure way and with private addressing. A VPN can be used with any type of traffic, without specific setup on the ...


1

Preventing lost and delayed packets affecting future connections is only a secondary purpose of TIME_WAIT1. TCP is hardened against such packets by virtue of the receive window and, in modern implementations, timestamps. Instead, TIME_WAIT's primary purpose is to handle the case in which the final ACK is lost. In such a case the final FIN will be re-received ...


1

i think the short short answer is: an example of what sender can do is here rfc6675 First, TCP receiver does not process SACK fields. SACK, as ACK, is sent by the receiver, i.e., receiver creates information in SACK, and is processed by the sender. On the receiver: The actions of the receiver on duplicate packets do not depend on SACK option. TCP receiver ...


1

Segment in this context refers to PAYLOAD OF TCP. L=0 toss it. Segment outside of window toss it. S<RCV.NXT+RCV.WND but that is where they mess up in the spec, and it gets fixed in a later RFC. Any S<RCV.NXT+RCV.WND will be accepted. Like a retransmission. ACKs, SACKS, and window updates are always processed. (The max is used to keep things straight ...


Only top voted, non community-wiki answers of a minimum length are eligible