The HTTP POST request is split into two TCP packets

App & System Services Networking
BeauJiang OP
Created Aug ’22
Replies 5
Boosts 0
Views 1.9k
Participants 4

Hello, recently we have been troubleshooting some POST interface slow problems on the server side, and found that the iOS client POST requests in the TCP transport layer are separated into two packages (header a package, body a package), check the relevant information found in other languages have a similar situation (like Ruby's Net::HTTP) , but no one mentioned that iOS development on the use of URLSession will also have similar problems. Is there any way to disable this packet splitting strategy ? POST requests like curl and Android are made in a single TCP packet containing all the content possible.

Replies  5
Boosts  0
Views  1.9k
Participants  4
Claude31 OP
Aug ’22

Is there any way to disable this packet splitting strategy

No. Splitting is a feature of TCP/IP. The upper layers (as http) have not to bother about it.

There are ways to set packet size, but that is a general conf setting.

If you are interested in technical details, some possibly useful read:

It seems most web sites out on the internet use 1460 bytes for the value of MTU.

1
Hoffman OP
Aug ’22

To rephrase the above (correct) reply... TCP is a stream service, and not a datagram service.

There is no correlation between the numbers of writes and the numbers of reads performed, just in the total volume of data transferred.

Or you can get a network error when the transfer fails to complete, of course.

Receiving an incoming kilobyte-sized transfer in one read, or obtaining that same arriving kilobyte data in a thousand single-byte reads, or anything between those two, are all equally valid and all possible.

Your apps are responsible for finding the beginning and the end of your data in the stream. This includes potentially reading and receiving part of some subsequent kilobyte-sized hunk of data also arriving at the end of one of your previous reads, if you allowed enough room in your read for that data.

Again, do not think of records or datagrams or numbers of reads and writes here. Not with TCP. Not with TLS, for that matter.

As for servers receiving HTTP or HTTPS (slowly), there are attacks that leverage similar behaviors. Slowloris is an example.

0
BeauJiang OP
Aug ’22

The situation I described above does not reach the upper limit of tcp packets.

Same situation: [https://gocardless.com/blog/in-search-of-performance-how-we-shaved-200ms-off-every-post-request/]

0
DTS Engineer OP
Apple
Aug ’22

If you care about performance, you aren’t using HTTP/1. If you re-test this with modern protocols, what do you see? Ideally that’d be HTTP/3, but HTTP/2 with TLS 1.3 would be a good start.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

1
BeauJiang OP
Aug ’22

We use HTTP/2 with TLS 1.3, The problem still exists and no change has occurred.

0
The HTTP POST request is split into two TCP packets
First post date Last post date
 
 
Q