简体   繁体   English

Google使用什么协议用于Gmail? (不是IMAP或POP)

[英]What protocol does Google use for Gmail? (not IMAP or POP)

You can access gmail either using the web interface, Google's Android client or using IMAP. 您可以使用网络界面,Google的Android客户端或使用IMAP访问Gmail。 As far as I can tell, the web interface and the Android app uses a completely different protocol than IMAP -- they are not just interfaces on top of it. 据我所知,网络界面和Android应用程序使用的协议与IMAP完全不同 - 它们不仅仅是接口。 The reason I'm sure of that is because the Android app can without problem open a folder with 1m mail in < 3 seconds. 我之所以确定这一点,是因为Android应用程序可以毫无问题地在<3秒内打开1m邮件的文件夹。 No plain IMAP client can do that. 没有普通的IMAP客户端可以做到这一点。

So my question is what is known about this secret protocol? 所以我的问题是这个秘密协议的知识是什么? Where is the reference documentation for it? 它的参考文档在哪里? Has it been reverse engineered? 是否进行了逆向工程? Does Google sanction its use? 谷歌是否批准其使用?

arnt's answer provides an excellent method to test gmail's raw imap speed: arnt的答案提供了一种测试gmail原始imap速度的绝佳方法:

$ openssl s_client -host imap.gmail.com -port 993 -crlf 
...
* OK Gimap ready for requests from 12.34.56.78
$ a LOGIN ***@*** ***
a OK
$ c SELECT "[Gmail]/All mail" !!!!
* FLAGS (\Answered \Flagged \Draft \Deleted \Seen)
* OK [PERMANENTFLAGS (\Answered \Flagged \Draft \Deleted \Seen \*)] Flags permitted.
* OK [UIDVALIDITY 673376278] UIDs valid.
* 1142417 EXISTS
* 0 RECENT
* OK [UIDNEXT 1159771] Predicted next UID.
* OK [HIGHESTMODSEQ 8670601]
c OK [READ-WRITE] [Gmail]/All mail selected. (Success)

The command I've marked, c SELECT "[Gmail]/All mail" takes about 20 seconds to complete. 我标记的命令, c SELECT "[Gmail]/All mail"大约需要20秒才能完成。 Since that time is larger than it takes for the GMail app on my relatively underpowered Android phone to startup and load the All mail label which does it in less than 6 seconds even after I purged its caches. 由于那个时间比我相对功能不足的Android手机上的GMail应用程序启动和加载所有邮件标签所花费的时间更长,即使在我清除其缓存后也不到6秒。 The web client is even faster. Web客户端甚至更快。

Unless I'm missing something basic this proves "beyond reasonable doubt" that Google's GMail clients does not use IMAP since you never ever have to wait 20 seconds for any SELECT command to complete. 除非我遗漏了一些基本内容,否则这证明“无可置疑”Google的GMail客户端不使用IMAP,因为您永远不需要等待20秒才能完成任何SELECT命令。

The Android app (at least the ones I've used) use IMAP. Android应用程序(至少是我使用的应用程序)使用IMAP。 You can verify this by running Wireshark on the server. 您可以通过在服务器上运行Wireshark来验证这一点。

As to why the Android app is so fast - what I know is that it uses the SEARCH command to select the most recent n messages. 至于为什么Android应用程序如此之快 - 我所知道的是它使用SEARCH命令来选择最近的n个消息。 Desktop clients such as Thunderbird or Outlook are much more heavy-weight and download headers and metadata for every message in the folder, despite recommendations for them not to. 桌面客户端(如Thunderbird或Outlook)的重量更轻,下载文件夹中每条消息的标题和元数据,尽管建议他们不要这样做。

A smartphone does not have the resources to store and process millions of emails (although more modern ones might be getting there) so the SEARCH approach allowed quick mail access for handheld devices. 智能手机没有足够的资源来存储和处理数百万封电子邮件(尽管更多现代电子邮件可能会到达那里),因此SEARCH方法允许手持设备快速访问邮件。

Anyhow, Wireshark can reveal a great deal about the behaviour of IMAP clients and servers. 无论如何,Wireshark可以揭示有关IMAP客户端和服务器行为的大量信息。 If you're really curious, give it a shot. 如果你真的很好奇,那就试一试吧。 You can't do this if the server is Gmail, but you can try it out on another server (eg hMailServer). 如果服务器是Gmail,则无法执行此操作,但您可以在其他服务器(例如hMailServer)上进行尝试。

After more research, I've found that there exists an API for GMail: https://developers.google.com/gmail/api/ I don't think that API was released when I posted this question back in 2013. 经过更多研究后,我发现GMail有一个API: https//developers.google.com/gmail/api/我不认为我在2013年发布此问题后发布了API。

Using that API, I have created a demo program that fetches the 100 last mails of a label: https://gist.github.com/bjourne/37a9d15b03862003008a1b0169190dbe 使用该API,我创建了一个演示程序,用于获取标签的最后100封邮件: https//gist.github.com/bjourne/37a9d15b03862003008a1b0169190dbe

The relevant part of the program is: 该计划的相关部分是:

resource = service.users().messages()
result = resource.list(userId = 'me', labelIds = [label]).execute()
mail_ids = [m['id'] for m in result['messages']]

start = time()
mails = []
batch = BatchHttpRequest()
cb = lambda req, res, exc: mails.append(to_mail(res))
for mail_id in mail_ids:
    get_request = resource.get(**headers_params(mail_id))
    batch.add(get_request, callback = cb)
result = batch.execute()
print('Took %.2f seconds' % (time() - start))

It lists the last 100 messages sorted by date in a label (folder in IMAP terminology) containing over 570k messages. 它列出了包含超过570k消息的标签(IMAP术语中的文件夹)中按日期排序的最后100条消息。

On my machine, this loop takes about 0.5 - 0.8 seconds. 在我的机器上,此循环大约需要0.5 - 0.8秒。 I can claim confidently that no pure IMAP client on the planet comes even close. 我可以自信地宣称,这个星球上没有纯粹的IMAP客户端 Likely, IMAP won't ever get faster because it is a poor fit for how Google stores mail internally. 可能,IMAP不会变得更快,因为它不适合Google内部存储邮件的方式。

So I'll answer my own question. 所以我会回答我自己的问题。 This is the API they are using and it wasn't exposed earlier. 这是他们正在使用的API,并且之前没有公开过。

"No other IMAP client can do this" is a pretty bold statement, but a million of messages is a pretty big number as well. “没有其他IMAP客户端可以做到这一点”是一个非常大胆的声明,但是数百万条消息也是一个相当大的数字。 I would encourage you to give Trojitá a try here. 我鼓励你在这里试试Trojitá Chances are that the initial synchronization will be rather slow (it would transfer the flags for that million of messages for various technical reasons related to how the IMAP flags, SELECT , SEARCH and STATUS are specified), but the subsequent resynchronizaiton should be lightning fast thanks to ESEARCH , CONDSTORE and QRESYNC . 有可能初始同步将相当缓慢(它会因为与指定IMAP标志, SELECTSEARCHSTATUS方式有关的各种技术原因而传输数百万条消息的标志),但随后的重新同步应该是闪电般的快速谢谢到ESEARCHCONDSTOREQRESYNC I would be interested to hear how well Trojitá works with your setup -- the contact information are on the homepage. 我很想知道Trojitá如何与您的设置一起工作 - 联系信息在主页上。

To your question -- most webmails nowadays provide a private API for their own use. 对于您的问题 - 现在大多数网络邮件都提供了一个供自己使用的私有API。 A typical architecture is to transfer messages about updated state via JSON, but there is no standard for this and the interface is prioprietary. 典型的体系结构是通过JSON传输有关更新状态的消息,但是没有标准,接口是专有的。 Chances are that the GMail "app" uses the same (or similar) method. 有可能GMail“app”使用相同(或类似)的方法。 You don't have much options to verify this as it is likely using TLS. 您没有太多选项可以验证这一点,因为它可能使用TLS。 With a web interface, it is trivial to see the traffic with an appropriate browser plugin, but not so much with a standalone Android application. 使用Web界面,使用适当的浏览器插件查看流量是微不足道的,但使用独立的Android应用程序则不是这么简单。

You can test gmail's IMAP performance easily (if you have a million-message mailbox). 您可以轻松测试gmail的IMAP性能(如果您有一个百万邮件邮箱)。 Open an IMAP connection with 打开IMAP连接

openssl s_client -connect imap.gmail.com:993 -crlf

then login and open your inbox. 然后登录并打开您的收件箱。

a login yourname@gmail.com yourpassword
b select inbox

Or open your allmail box if inbox isn't big enough (name may vary depending on UI language): 如果收件箱不够大,请打开您的邮箱(名称可能因UI语言而异):

c select "[Gmail]/All Mail"

If SELECT is fast but an IMAP client slow, then that's because the client sends additional/unneeded slow commands. 如果SELECT很快但IMAP客户端速度很慢,那么这是因为客户端发送了额外/不需要的慢命令。 Many choose to fill or update a data structure for the entire million messages even if they're going to display only 40 messages. 许多人选择填写或更新整个百万条消息的数据结构,即使它们只显示40条消息。 That's client choice, not IMAP slowness. 这是客户的选择,而不是IMAP的缓慢。

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM