A major tenet of TCP/IP and the Internet architecture is the end-to-end principle, taking the TCP/IP out of software fits poorly with the idea.

Of course in the real world people have tried it, but it hasn't caught on. There are some niche "specialized hardware talking to specialized hardware" applications where it lives on (RDMA in HPC for example).

The limited TCP acceleration features in ethernet cards that are only used in amenable circumstances have been significant sources of headache and mysterious data corruption bugs, but they have eventually become pretty common HW features - not sure how often the feature is actually used.

The need has also decreased in end-user hardware, since broadband has largely stopped getting faster - we don't have the 10-100 Gbit Internet connections that the curve from the early 2000's would have lead to. Instead we transitioned to choppy 4G on iPhones and left broadband to stagnate...

TCP and IP header checksum offloading is pretty ubiquitous, along with segmentation offloads (i.e. https://en.wikipedia.org/wiki/Large_send_offload).

There is a more heavy handed offload in what Windows calls "TCP Chimney Offload" (https://docs.microsoft.com/en-us/windows-hardware/drivers/ne...), but it isn't as commonly used and is generally disfavored.

There have been NICs that integrate TCP/IP offload features[1]. I'm not sure how widely used they are anymore. It seems when CPU clock frequencies leveled off, and core count started to increase (~10 years ago), there was less rationale to use dedicated hardware versus consuming more available CPU/core resources to deal with the network protocol processing in software.

1 - https://en.wikipedia.org/wiki/TCP_offload_engine

I worked multiple years in writing drivers or low level libraries for companies building network cards (mainly in finance). I also do a lot of networking/electronics at home, including building simple network cards. To answer your question "'m not sure how widely used they are anymore": I would say it's almost impossible nowadays to find an ethernet-only chip that does not have any kind of tcp offload ("toe" for short). 90% of the times the chip also handles ARP & ICMP for you. Most recent drivers are able to offload most of the work to the ship, and fallback on software for complementary features (most on-chip TOEs are still barebone) or when no TOE is present.

All Intel NICs do TCP offload, they are quite widely used.

Do you have a source for more information? I know Intel NICs are mostly regarded pretty highly.

I don't know much about it, but it's briefly described here: https://www.intel.com/content/www/us/en/support/network-and-... (ctrl-f offload)

https://wiki.linuxfoundation.org/networking/toe suggests it's done mostly in closed-source firmware.

An ethernet chip deals with ethernet, at the link layer. TCP is higher up in the stack and not necessary to process ethernet. A few unique network interfaces are designed to process some aspects of IP, and sometimes TCP, to support specific performance demands. TCP will generally be implemented in software/firmware because it's complex and connection-oriented.

A fair number of ethernet chips will handle all the TCP protocol themselves, the upper layers just pass in the address of a large buffer and the chip will take care of chopping it up into packets.

The feature is usually called a "TCP Offload Engine".

That's hardly all the TCP protocol though, it's just the segmentation and checksumming part.

Segmentation and checksumming are very common, with the segmentation often called TSO (Transmission Segmentation Offload) for send and LRO (Large Receive Offload) for receive. However, usually when referred to as a TCP Offload Engine (ToE) it does mean pretty much the whole protocol, as least a functional subset of it anyway. Windows and FreeBSD support ToE with some NICs. Linux has rejected full ToE in mainline for a number of pretty solid reasons:

https://wiki.linuxfoundation.org/networking/toe