tcpip - What's the difference between a TCP segment and a TCP packet?

  • use753231

    Is a TCP segment not part of a TCP packet?

    Here's what I've read:

    A segment is a piece of application data chopped into a transportable size by TCP and wrapped with a TCP header

    Isn't the TCP header itself made up of segments?

  • Answers
  • Ricardo Cristian Ramirez

    We say TCP segment is the protocol data unit which consists a TCP header and an application data piece (packet) which comes from the (upper) Application Layer. Transport layer data is generally named as segment and network layer data unit is named as datagram but when we use UDP as transport layer protocol we don't say UDP segment, instead, we say UDP datagram. I think this is because we do not segmentate UDP data unit (segmentation is made in transport layer when we use TCP).

    Data Encapsulation and the TCP/IP Protocol Stack

  • Spiff

    The original TCP RFC is kind of fuzzy with how it uses the term "segment".

    In some cases, the term "segment" refers to just the current piece of the application data stream that's being transmitted, which excludes the TCP headers. For example, the TCP "Maximum Segment Size" (MSS) is the maximum size of the application data chunk in this message, not counting the TCP headers.

    But in other cases the term "segment" includes the whole TCP message, including the TCP headers. In fact in at least one case the spec mentions TCP segments with no application data (such as plain Acks).

    A single whole IP message is a "datagram".

    The original IP RFC refers to link-layer messages as "packets". IP datagrams can be broken into "fragments" to fit into the packet size limits on small-packet networks.

    The IEEE 802.3 / Ethernet link layer refers to a single contiguous physical-layer transmission as a "packet". The MAC data-link portion of the packet is called the "frame". The frame begins with the destination MAC address and ends with the Frame Check Sequence. The part of the frame that may contain an IP datagram (or fragment thereof) is called the "MAC Client Data field".

    So, technically, there is no such thing as a "TCP packet" or an "IP packet". Packets are terms from the layers below IP. TCP has "segments", and IP has "datagrams".

  • Florenz Kley

    The TCP header, also referred to as "segment header", and the payload, or data, or "segment data" make up the TCP segment, of varying size.

  • Florenz Kley

    A header is not made up of segments. A header always has the same size and must be complete. Otherwise, the packet could not be decoded.

    What you refer to as "Segment" is the whole "packet" that is later on combined with others to the TCP stream. See:

    Transmission Control Protocol accepts data from a data stream, 'segments' it into chunks, and adds a TCP header creating a TCP segment.

  • Lovej

    A TCP Segment is called a Datagram. Typically,a Segment or a datagram is a Packet. When the datagram or packet is processed by the Network layer, it adds the IP Header to the data and it becomes a IP Packet.

    Transport layer segments the data into smaller units called Segments, datagrams or so called packets. But we usually refer them as Segments.

  • sinni800

    A TCP segment IS a packet. A segment is only a part of a TCP connection stream between two computers. A datagram is a "packet" in UDP terms.

  • cpx

    An IP packet is made up of an IP header with data attached. The data, is a TCP header and a segment of application data, called TCP Segment. TCP Segement is what you usually call a TCP Packet.

  • ultrasawblade

    The "generic" term for things like this is Protocol Data Unit, or PDU.

    -------   ------------   ----------------------   --------------------------
    Layer 1 - Physical     - Transceiver            - bits, or a physical signal
    Layer 2 - Datalink     - Ethernet               - frame
    Layer 3 - Network      - IP                     - packet
    Layer 4 - Transport    - TCP                    - segment
    Layer 5 - Session      - SIP                    - data, request, or response
    Layer 6 - Presentation - Encryption/compression - data, request, or response
    Layer 7 - Application  - HTTP                   - data, request, or response

    Things kind of get blurry with specific protocols from layer 4 and up (for example, to this day I don't know of anything that's really purely a session protocol, and there really isn't such a thing as a common "presentation" protocol but it's defintely almost separate layer in a lot of software/communication stacks).

    Also, as previously mentioned, each one of these PDU's has a header that's distinct from its payload, or data. The header has information about the data and possibly a checksum for verification on the other end.

  • Jasper

    TCP receives data from the application layer and 'chops' this data into several data-segments; pieces of the original data with an added TCP header. Part of this header is a sequence-number which is used by the TCP protocol on the receiving-end to put all received segments (minus the headers) in the right order and re-assemble the original data which it then transfers to the application layer.

    So, to answer your question; the term 'TCP packet' doesn't really exist. It is called a 'segment' which consists of a header and a data-section. The header itself consists of several 'fields' which contain, among others, a sequence number, checksum and source- and destination port numbers.

  • Roger VEBER

    When you send data thought a TCP connection, the amount of data you send may exceed the maximum size of bytes allowed by the connection in a single packet. This amount "Maximum Segment Size" (also called MSS) is "negotiated"(1) at the connection time between the two TCP end-points (the client and the server). The OSI level 4 protocol TCP is responsible of the scatter/gather. It means that your data stream is split into smaller parts (called the segments) and sent separately through the network. At the other side, the TCP layer is responsible of re-gathering the packet in the correct order to reform the stream just like it was sent. Nothing can tell you that the segments will arrive at the destination in the same order than at the departure. That is also why packets are numbered. More, packets are acknowledged one by one separately(2) by the receiver but sometime packets can be lost. Then no ACK will be returned from the destination of the packet to the emitter. Then the emitter should resend it (that is also the role of TCP). Sometime the packet is received correctly but the ack is not received by the emitter (lost packet again). In such a case, the emitter will resend it, but the receiver sees that it already received it (that is a Dup packet) and eliminate it but resend the ack to the sender.

    Also to improve throughput the emitter can send several packets in series and do not have to wait for the previous ack to send the next packet. It is also part of TCP protocol and it is called sliding windows. The number of sent packet pending for an ack is limited.

    (1) In facts, there are no negotiation at all, each end-point tells the Maximum Size he is able to deal with. This value do not include the 20 bytes of IP Header, neither the 20 bytes of TCP Header. (2) several packets can also be acknowledged by a single ACK.

    Keep in mind that Datagrams are encapsulated data sent on a IP network or using a connection-less protocol like UDP. Packets are encapsulated data for a connexion-oriented protocol like TCP. Segments are portions of a data stream sent on TCP. See W.Richard Stevens "TCP/IP illustrated" to have a far better explanation of all this stuff.

  • albert

    tcp segment is only a concept, it's different with ip defragment

    when you send data that is bigger than ip mtu, it is put into one ip packet, but the ip layer then find the ip packet is too long to transmit,so it will split big packet into several pieces, each of them have the same Identifier but with different offset and data length. the receive side is responsible for collecting all the pieces, after received all the pieces it will reassemble all the pieces into one whole ip packet and push it to upper protocol layer.

    but the tcp layer have different behavior. when you send a data that is big enough, the tcp layer won't put the data into one tcp packet then split them into pieces(but ip does), it retrieve a part of the raw data into one tcp packet and then push the tcp packet to ip layer, the length of the tcp packet is determined by mss, later it will retrieve another part of the rest data into another tcp packet, and repeat the process till all the data are transmitted.

    if tcp don't use mss,it is horrible. assume you send a data that is bigger than mss, it will be put into only one tcp packet(data is not split into small pieces due to mss not used), tcp packet is bigger than ip mtu, so the ip will split the tcp packet into pieces. the tcp packet will re-transmit if any one of the pieces is lost, waste time and bandwith

    ps: tcp_mss = ip_mtu - tcp_header

  • Related Question

    Linux Kernel Packet Forwarding Performance
  • Bob Somers

    I've been using a Linux box as a router for some time now. Nothing too fancy, just enabling forwarding in the kernel, turning on masquerading, and setting up iptables to poke a few holes in the firewall.

    Recently a friend of mine pointed out a performance problem. Single TCP connections seem to experience very poor performance. You have to open multiple parallel TCP connections to get decent speed.

    For example, I have a 10 Mbit internet connection. When I download a file from a known-fast source using something like the DownThemAll! extension for Firefox (which opens multiple parallel TCP connections) I can get it to max out my downstream bandwidth at around 1 MB/s. However, when I download the same file using the built-in download manager in Firefox (uses only a single TCP connection) it starts fast and the speed tanks until it tops out around 100 KB/s to 350 KB/s.

    I've checked the internal network and it doesn't seem to have any problems. Everything goes through a 100 Mbit switch. I've also run iperf both internally (from the router to my desktop) and externally (from my desktop to a Linux box I own out on the net) and haven't seen any problems. It tops out around 1 MB/s like it should. also reports 10 Mbits speeds.

    The load on the Linux machine is around 0.00, 0.00, 0.00 all the time, and it's got plenty of free RAM. It's an older laptop with a Pentium M 1.6 GHz processor and 1 GB of RAM. The internal network is connected to the built in Intel NIC and the cable modem is connected to a Netgear FA511 32-bit PCMCIA network card.

    I think the problem is with the packet forwarding in the router, but I honestly am not sure where the problem could be. Is there anything that would substantially slow down a single TCP stream?

  • Related Answers
  • Bob Somers

    The problem has been fixed. There was some sort of hardware issue (still no idea what) on the machine. After installing the same Linux distro and reconfiguring the firewall and packet forwarding the same way on a different machine, I'm no longer having the problem.


  • David Spillett

    This is most likely a per-stream performance issue at either the remote end or your ISP - each individual stream is being throttled, either deliberately (by your ISP) or just due to congestion (at the remote site, at your ISP, or anywhere in between).

    It is unlikely to be a fault at your end.

    As an example of how this works when the issue is congestion, imagine a web server with a 10000Kbyte/sec connection and no other limits/bottlenecks. If there are 100 active connections downloading large objects they'll each (ignoring variances caused by latency and congestion differences between each client and the server) get around 100Kbyte/sec on average. If you opened five connections instead of one, you would get something more like 480Kbyte/sec (10000/104*5) while each single stream gets something along the lines of 95Kbyte/sec (10000/104*1). Of course in this example you are the only one using multiple connections, which is unlikely to be the case in real life. And also this math only works if the traffic management under congestion results in a fair average rate given to each stream, again in real life there are many factors that will cause this to vary, and the traffic management may impose some per host limits on top of any explicit or implied per stream ones.