Aplicación cliente-server iOS: HTTP o TCP / IP?

Estoy a punto de comenzar a diseñar / desarrollar una aplicación para iOS de server cliente. Me inclino hacia el uso de requestes HTTP para get / publicar datos desde / hacia un server, pero quiero asegurarme de que esta sea la decisión correcta. ¿Cuáles son los beneficios de usar sockets sobre requestes HTTP? ¿Las tomas son más rápidas? Una razón por la que me inclino hacia http es que también quiero tener una interfaz web y una interfaz de iOS. Si creo web services PHP que el iOS y la aplicación web puedan tener acceso, creo que estoy networkinguciendo el time de desarrollo.

Por cierto, he leído estos tutoriales , que proporcionan algunos beneficios de los sockets, pero ninguno de los beneficios mencionados son necesariamente cambios de juego. Excepto que no entiendo completamente lo que quiere decir con "Puedes enviar solo los datos exactos que necesitas enviar, haciendo que tu protocolo sea ágil y eficiente". ¿Alguien sabe lo que quiere decir aquí?

Gracias por adelantado.

    HTTP es solo una capa por encima de TCP, por lo que también está "basada en socket". Yo usaría HTTP, por ejemplo, porque hay HTTPS para los casos en que se necesita una comunicación segura. Otra ventaja de HTTP (S) sobre un protocolo TCP personalizado es que los cortafuegos suelen tener un agujero de alfiler para el puerto TCP que utiliza (HTTP: 80, HTTPS: 443).

    En términos de con qué ir, debe seguir con HTTP a less que sepa cómo garantizar la security a través de una connection de zócalo y puede manejar adecuadamente los times de espera, etc.

    Lo que quiere decir al enviar solo los datos exactos que necesita es HTTP es un protocolo con varias capas de abstracción entre el post que está tratando de enviar y el sobre en el que está siendo enviado.

    Ejemplo de una request HTTP:

     (pidiendo datos)
     GET / dumprequest HTTP / 1.1
     Anfitrión: djce.org.uk
     Usuario-agente: Mozilla / 5.0 (Ubuntu; X11; Linux x86_64; rv: 8.0) Gecko / 20100101 Firefox / 8.0
     Aceptar: text / html, aplicación / xhtml + xml, aplicación / xml; q = 0.9, * / *; q = 0.8
     Accept-Language: es-es, en; q = 0.5
     Accept-Encoding: gzip, deflate
     Accept-Charset: ISO-8859-1, utf-8; q = 0.7, *; q = 0.7
     Conexión: keep-alive
    
     (recibiendo datos)
     HTTP / 1.1 200 OK
     Fecha: martes 13 de diciembre de 2011 01:09:14 GMT
     Servidor: Apache / 2.2.9 (Ubuntu) DAV / 2 SVN / 1.5.1 PHP / 5.2.6-2ubuntu4.6 con Suhosin-Patch mod_ssl / 2.2.9 OpenSSL / 0.9.8g mod_perl / 2.0.4 Perl / v5. 10,0
     Content-Location: dumprequest.pp
     Variar: negociar
     TCN: elección
     Keep-Alive: timeout = 15, max = 100
     Conexión: Keep-Alive
     Transfer-Encoding: fragmentado
     Tipo de contenido: text / html;  charset = utf-8
    
     * un documento HTML bastante grande aquí, con datos en algún lugar del cuerpo *
    

    Ejemplo de una request de socket:

     (pidiendo datos)
     encuesta
    
     (recibiendo datos)
     *datos*
    

    Eso es mucho más simplificado que lo que haría con un socket en realidad (puede crear su propio formatting de serialization para las requestes para mantenerlos compactos, pero es casi seguro que no va a tener solo un command de "sondeo"), pero obtiene el idea. Descartas un montón de cosas adicionales que deben analizarse y obtienes solo los datos sin procesar.

    Por supuesto, en realidad cualquier package que envíe se envolverá en una ttwig PPP / Ethernet, luego en una ttwig AAL5 si usa ADSL, etc. Esto es lo que dice @ hotpaw2. La eficiencia del mundo real de los sockets a través de TCP / IP frente a HTTP a través de TCP / IP es a veces perceptible, pero otras veces no. Depende completamente de su caso de uso (con qué frecuencia deben enviarse las cosas, cuán grandes serán los packages).

    Significa que cuando usa HTTP necesitará enviar el verbo de request de protocolo HTTP (GET, POST, etc.) y, en general, obedecer las reglas HTTP. Al usar sockets, puedes enviar lo que quieras y nada más.
    Para responder a su pregunta, necesitaríamos saber más sobre su request. Aquí hay algunas reglas a las que me atengo:

    1. juego – tcp
    2. cualquier cosa en time real – tcp
    3. database frontend (operaciones CRUD en datos), networkinges sociales, juegos no en time real – http / restful services / json
    4. el frontend de la database que desea exponer como una API a los clientes empresariales: considere SOAP

    En realidad, es posible que desee consultar los WebSockets de HTML5: combinan el concepto de protocolos configurables a través de http / s y evitan el ancho de banda tradicional solicitado por Ajax httprequests. Google, vale la pena, y es el estándar que viene, dado que tanto Google como Apple lo están apoyando en Safari y Chrome. Cuando hayas terminado con lo que te estás acercando para comenzar ahora, probablemente se instalará de manera confiable en todos los dispositivos.

    HTTP requiere enviar varias docenas de bytes de información de encabezado HTTP requerida. Los zócalos sin procesar pueden ser un pellizco más eficiente al dejar esos bytes de encabezado desactivados. Pero en realidad, después de todo el almacenamiento en búfer y el empaquetado del hardware a través de múltiples saltos de networking, la diferencia puede no ser medible.

    Es less probable que HTTP sea bloqueado por quien provea el acceso neto en sentido ascendente que el número de puerto J aleatorio.