I had a similar case with a client many years ago. My first inspection with Trace revealed both this and that in bad habits, but not the explanation to the problem with high I/O spikes. An MVP colleague gave me the tip to look at sys.dm_db_index_logical_stats and check for high values of physical reads. Indeed one table stood out, and inspecting my trace, I found that there was a query that ran SELECT * without WHERE on this 8GB table. On a 10GB server...
So that is something you can try. But obviously, the cause may be something which does not display there. For instance, a backup would not. And as I understand it, the traffic is only between the SQL machine and the web server, but theoretically, it could be something outside SQL Server that sends this data.