I have used this information to help make recommendations to clients for different architectural configurations.
Rather than duplicate information here is the official link to this information:
Choose the "Channel & Endpoint Recommendations" Link....
The NIO AMF/HTTP endpoints in LCDS 2.6 use the same client-side Channel classes as their servlet-based endpoint counterparts in BlazeDS. They just scale better than the servlet based endpoints. If the web app is not servicing general servlet requests, you can configure the servlet container to bind non-standard HTTP/S ports leaving 80 and 443 free to be used by your LCDS NIO endpoints. Because LCDS is a super-set of BlazeDS, you still have access to the servlet-based endpoints if you want to use them instead.
Reasons to use the servlet-based endpoints could be because you need to include 3rd party servlet filter processing of requests/responses or need to access data structures in the application server's HttpSession.
IMPORTANT: The NIO HTTP endpoints are not part of the servlet pipeline, so while they provide a FlexSession in the same manner that RTMP connections do, these session instances are disjoint from the J2EE HttpSession.
Many people wonder how to secure an RTMP Connection. While there are many options one that I have found works well if to develop an SSO mechanism which keeps HTTP Session in Sync with RTMP Session in LCDS using Context and Session Listeners; using a java.security.Principal in a HashMap as the sync token. I have to give credit to Peter Martin for pioneering this solution. This can be complex but can serve as a way to secure your RTMP connections against the same security constraints that your HTTP Requests must adhere to.