I think it's all a bit "in the eye of the beholder" as far as protocols. Here I mean the message patterns and implicit state models, ignoring software design choices.
I'd say the IP protocol is asynchronous in terms of flinging individual packets around. They can be buffered, delayed, etc. They can arrive at the recipient without notice.
TCP starts to make it "more synchronous" since the two parties have to signal back and forth negotiate coordinated buffers and perform a sequence of steps within timeout deadlines.
SMTP seems more asynchronous in terms of whole messages being delivered and stored without protocol-level coordination between messages.
Non-pipelined HTTP 1.1 is both "more synchronous" and "less synchronous". It adds more timing behavior to the use of TCP to have simplex phases of client-sending and server-sending. At the same time, you can think of the request and response messages a bit like email messages to be stored and forwarded. But there are narrower response time limits for an HTTP message pair to succeed or fail at the transport level compared to a message and reply via email.
Of course, these different scenarios are happening all at once in a normal SMTP or HTTP exchange. So the abstractions layered over introduce new protocol units which may have synchronous or asynchronous characteristics, while the underlying primitives continue to also occur with their own apparent characteristics.
A similar issue exists with voice over IP. The protocol is duplex streams which seems quite asynchronous to me. But a typical conversation involves synchronization at human language boundaries and is quite sensitive to latency. Conference calls can fall apart when participants lose synchronization and start talking over each other. This is a social communication protocol layered over the underlying audio streaming protocol.
I'd say the IP protocol is asynchronous in terms of flinging individual packets around. They can be buffered, delayed, etc. They can arrive at the recipient without notice.
TCP starts to make it "more synchronous" since the two parties have to signal back and forth negotiate coordinated buffers and perform a sequence of steps within timeout deadlines.
SMTP seems more asynchronous in terms of whole messages being delivered and stored without protocol-level coordination between messages.
Non-pipelined HTTP 1.1 is both "more synchronous" and "less synchronous". It adds more timing behavior to the use of TCP to have simplex phases of client-sending and server-sending. At the same time, you can think of the request and response messages a bit like email messages to be stored and forwarded. But there are narrower response time limits for an HTTP message pair to succeed or fail at the transport level compared to a message and reply via email.
Of course, these different scenarios are happening all at once in a normal SMTP or HTTP exchange. So the abstractions layered over introduce new protocol units which may have synchronous or asynchronous characteristics, while the underlying primitives continue to also occur with their own apparent characteristics.
A similar issue exists with voice over IP. The protocol is duplex streams which seems quite asynchronous to me. But a typical conversation involves synchronization at human language boundaries and is quite sensitive to latency. Conference calls can fall apart when participants lose synchronization and start talking over each other. This is a social communication protocol layered over the underlying audio streaming protocol.