3주차 정리

Application Layer)

 

OSI 7 Layer모델의 가장 상위 계층인 Application 계층은 사용자와 네트워크 간의 인터페이스 역할을 합니다.

이 계층에서는 사용자가 애플리케이션 소프트웨어를 통해 데이터를 생성하고, 이 데이터를 네트워크로 전송하며, 수신 측에서는 이 데이터를 해석하여 애플리케이션에 제공합니다.

즉, 이 계층은 애플리케이션에 대한 프로토콜과 인터페이스를 제공하며, 이를 통해 데이터 전송이 이루어지게 됩니다. 예를 들어, 웹 브라우저에서 HTTP 프로토콜을 사용하여 웹 페이지를 요청하고, 이를 수신하는 서버 측에서는 HTTP 프로토콜을 사용하여 요청에 대한 응답을 전송합니다.

Application 계층은 사용자와 애플리케이션 간의 상호 작용을 위한 표준 인터페이스를 제공하며, 이를 통해 데이터 통신이 가능해집니다.

 

예시 : 웹 브라우저(HTTP), 이메일(SMTP), 파일전송(FTP)

 

• 웹 브라우저 (Web Browser): HTTP 프로토콜을 사용하여 웹 페이지를 요청하고, 이를 수신하는 서버 측에서는 HTTP 프로토콜을 사용하여 요청에 대한 응답을 전송합니다. 웹 브라우저는 이러한 HTTP 프로토콜을 사용하여 사용자가 인터넷에서 웹 페이지를 검색하고, 해당 웹 페이지의 내용을 확인할 수 있게 해줍니다.

 

• 이메일 (Email): SMTP (Simple Mail Transfer Protocol) 프로토콜을 사용하여 이메일을 보내고, POP3 (Post Office Protocol version 3) 또는 IMAP (Internet Message Access Protocol) 프로토콜을 사용하여 이메일을 받을 수 있습니다. 이메일 클라이언트는 이러한 프로토콜을 사용하여 사용자가 이메일을 보내고, 받는 것을 도와줍니다.

 

• 파일 전송 (File Transfer): FTP (File Transfer Protocol) 프로토콜을 사용하여 파일을 전송할 수 있습니다. FTP 클라이언트는 이러한 프로토콜을 사용하여 사용자가 파일을 업로드하고, 다운로드할 수 있게 해줍니다. 이를 통해, 파일 전송이 간편하고 안정적으로 이루어질 수 있습니다.

 

TCP/IP Protocol Stack)

 

TCP/IP 프로토콜 스택은 OSI 모델과는 다른 4개의 계층으로 구성됩니다.

 

 

 

• Application Layer (응용 계층): 이 계층에서는 다양한 애플리케이션 프로토콜이 사용됩니다. 예를 들어, 웹 브라우저에서 HTTP, 이메일에서 SMTP/POP3/IMAP, 파일 전송에서 FTP 등의 프로토콜이 이용됩니다. 이 계층은 사용자와 서버 간의 상호작용을 지원하며, 데이터의 형식과 인터페이스를 제공합니다.

 

• Transport Layer (전송 계층): 이 계층에서는 TCP (Transmission Control Protocol) 및 UDP (User Datagram Protocol) 프로토콜이 사용됩니다. TCP는 신뢰성 있는 데이터 전송을 위해 사용되고, UDP는 신뢰성이 중요하지 않은 데이터 전송에 사용됩니다. 애플리케이션 계층에서 전송할 데이터를 TCP 또는 UDP 패킷으로 나누어 전송하게 됩니다.

 

• Internet Layer (인터넷 계층): 이 계층에서는 IP (Internet Protocol) 프로토콜이 사용됩니다. IP는 데이터를 목적지까지 라우팅하는 역할을 하며, 패킷의 주소와 목적지 주소를 설정합니다.

 

• Network Access Layer (네트워크 접속 계층): 이 계층에서는 네트워크 인터페이스 카드와 같은 하드웨어 장치와 드라이버, 프로토콜 등이 사용됩니다. 이 계층에서는 데이터를 전송하기 위해 필요한 물리적인 인터페이스와 하드웨어 접근 방법 등이 설정됩니다.

 

따라서, 애플리케이션 계층에서는 HTTP, SMTP/POP3/IMAP, FTP 등의 프로토콜을 사용하여 사용자와 서버 간의 데이터 전송이 이루어지고, 이를 전송 계층에서 TCP 또는 UDP 패킷으로 나누어 전송하게 됩니다. 인터넷 계층에서는 패킷의 주소와 목적지 주소를 설정하며, 네트워크 접속 계층에서는 물리적인 인터페이스와 하드웨어 접근 방법 등이 설정됩니다.

 

 

Socket)

 

소켓(Socket)은 컴퓨터 네트워크에서 프로세스 간 통신을 가능하게 해주는 인터페이스입니다. 소켓은 프로세스가 네트워크를 통해 데이터를 송수신하기 위한 접근점입니다.

 

소켓 프로그래밍(Socket Programming)은 소켓 인터페이스를 사용하여 네트워크를 통해 데이터를 주고받는 프로그래밍 기술을 말합니다. 소켓 프로그래밍은 서버와 클라이언트 간 통신에 많이 사용됩니다.

 

 

 

 

서버는 소켓을 생성하고 클라이언트의 연결 요청을 기다리며, 클라이언트는 소켓을 생성하고 서버에 연결을 요청합니다. 이후에는 서버와 클라이언트 간에 데이터를 주고받을 수 있습니다.

소켓 프로그래밍에서는 일반적으로 TCP와 UDP 프로토콜이 사용됩니다. TCP는 신뢰성 있는 데이터 전송을 보장하지만, UDP는 데이터 전송에 대한 보장이 없습니다.

소켓 프로그래밍은 다양한 언어로 구현될 수 있으며, C, C++, Java, Python 등에서도 사용됩니다. 소켓 프로그래밍을 통해 클라이언트와 서버 간에 데이터를 주고받을 수 있어, 다양한 네트워크 기반 애플리케이션을 개발할 수 있습니다.

 

HTTP/TCP 프로토콜 구조)

 

HTTP(HTTP Protocol)는 월드 와이드 웹(World Wide Web)에서 사용되는 프로토콜 중 하나로, 클라이언트와 서버 간의 통신을 위한 애플리케이션 계층(Application Layer) 프로토콜입니다. HTTP는 일반적으로 TCP를 사용하며, 포트번호 80번을 사용합니다. HTTP는 요청-응답(request-response) 모델을 사용하여 동작합니다.

 

TCP(TCP Protocol)는 인터넷 프로토콜 스위트(Internet Protocol Suite)에서 사용되는 전송 계층(Transport Layer) 프로토콜입니다. TCP는 신뢰성 있는 데이터 전송을 보장하기 위해, 오류 검출과 재전송 등의 기능을 제공합니다. TCP는 포트번호를 사용하여 송수신 프로세스를 구분하며, 3-way handshake를 통해 연결을 설정합니다.

 

HTTP와 TCP는 다음과 같은 구조로 이루어져 있습니다.

1. HTTP 구조

 

 

 

• HTTP Request: 클라이언트에서 서버로 요청을 보낼 때 사용됩니다. HTTP Request는 Request Line, Header, Body로 구성됩니다.
• Request Line: 요청 메서드, URI, HTTP 버전 정보를 포함합니다.
• Header: 요청에 대한 부가적인 정보를 포함합니다.
• Body: 요청과 함께 전송되는 데이터를 포함합니다.

HTTP Request Header:

• Host: 요청한 호스트의 도메인 이름을 나타냅니다.
• User-Agent: 클라이언트의 정보를 나타내는 문자열입니다.
• Accept: 클라이언트가 처리할 수 있는 미디어 타입을 지정합니다.
• Accept-Language: 클라이언트가 선호하는 언어를 나타냅니다.
• Cookie: 서버가 이전 요청에서 전송한 쿠키를 포함합니다.
• Authorization: 클라이언트가 인증 토큰을 전송할 때 사용됩니다.

 

• HTTP Response: 서버에서 클라이언트로 응답을 보낼 때 사용됩니다. HTTP Response는 Status Line, Header, Body로 구성됩니다.
• Status Line: HTTP 버전 정보, 상태 코드, 상태 메시지를 포함합니다.
• Header: 응답에 대한 부가적인 정보를 포함합니다.
• Body: 응답과 함께 전송되는 데이터를 포함합니다.

 

HTTP Response Header:

• Content-Type: 응답으로 전송되는 데이터의 미디어 타입을 나타냅니다.
• Content-Length: 응답으로 전송되는 데이터의 크기를 나타냅니다.
• Server: 서버의 소프트웨어 정보를 나타냅니다.
• Set-Cookie: 서버에서 클라이언트로 쿠키를 전송할 때 사용됩니다.
• Location: 클라이언트를 다른 URI로 이동시키기 위해 사용됩니다.
• Cache-Control: 캐시 제어 정보를 나타냅니다.

 

1. TCP 구조

• TCP 세그먼트: 데이터를 전송할 때 사용되며, TCP 세그먼트는 Header와 Data로 구성됩니다.
• Header: 포트번호, 시퀀스 번호, 확인 응답 번호 등의 정보를 포함합니다.
• Data: 실제로 전송되는 데이터를 포함합니다.

 

HTTP는 TCP의 상위 계층에 위치하며, TCP를 이용하여 데이터를 전송합니다. HTTP 요청과 응답은 TCP 세그먼트로 캡슐화되어 전송됩니다. TCP는 신뢰성 있는 데이터 전송을 보장하기 위해 오류 검출과 재전송 등의 기능을 제공하며, HTTP는 이를 이용하여 웹 브라우저와 웹 서버 간의 안정적인 통신을 보장합니다.

 

TCP & UDP)

 

TCP과 UDP는 인터넷 프로토콜 스택에서 주로 사용되는 전송 계층 프로토콜 중 두 가지입니다.

 

 

TCP:

 

TCP (Transmission Control Protocol)은 신뢰성있는 연결 지향 프로토콜입니다. 이는 데이터를 전송하기 전에 수신측과의 연결을 설정하고, 데이터를 전송한 후 연결을 해제하는 방식으로 동작합니다.

 

TCP는 Reliable Transport (신뢰성 있는 전송), Flow Control (흐름 제어), Congestion Control (혼잡 제어)를 제공합니다. Reliable Transport는 데이터가 손실되거나 손상되지 않도록 보장합니다.

 

Flow Control은 데이터 송수신 간의 데이터 전송 속도를 제어하여 수신측의 버퍼 오버플로우를 방지합니다.

 

Congestion Control은 네트워크의 혼잡 상태를 감지하여 데이터 전송 속도를 조절하여 네트워크 혼잡을 완화합니다. 또한 TCP는 데이터의 순서를 보장하고, 중복된 데이터 전송을 방지합니다.

 

이러한 특성으로 TCP는 웹 페이지, 이메일 등과 같은 신뢰성 있는 데이터 전송에 주로 사용됩니다.

 

 

UDP:

 

UDP (User Datagram Protocol)는 비신뢰적인 데이터 전송 프로토콜입니다. 이는 데이터를 전송하기 전에 연결을 설정하지 않으며, 데이터를 전송한 후 연결을 해제하지 않습니다.

 

UDP는 Reliable Transport (신뢰성 있는 전송)를 제공하지 않으며, Flow Control (흐름 제어) 및 Congestion Control (혼잡 제어)를 제공하지 않습니다.

 

UDP는 전송 속도가 빠르고, 간단한 데이터 전송에 주로 사용됩니다. 예를 들어, 비디오 스트리밍, DNS, SNMP 등의 애플리케이션에서 사용됩니다.

 

따라서 TCP는 신뢰성이 중요한 데이터 전송에 사용되고, UDP는 신뢰성이 크게 중요하지 않은 데이터 전송에 사용됩니다.

 

 

 

Application Layer에서 사용되는 프로토콜들은 위와 같고 이때 Tranport Layer에서 사용되는 프로토콜도 확인 할 수 있다.

 

3-Way Handshake & 4-Way Handshake)

 

TCP에서 3-way handshake는 TCP 연결을 설정하는 방법입니다. 이 과정에서 클라이언트와 서버 간에 세 개의 메시지가 교환됩니다.

1. 클라이언트는 SYN (Synchronize) 메시지를 서버에게 보냅니다. 이 메시지는 클라이언트가 서버와 통신하려는 의도를 나타냅니다. SYN 메시지에는 클라이언트의 초기 순차 번호 (ISN)가 포함됩니다.
2. 서버는 SYN 메시지를 받고, 클라이언트에게 ACK (Acknowledgement) 메시지와 SYN 메시지를 보냅니다. 이는 서버가 클라이언트의 요청을 수락하고, 클라이언트와 서버 간의 연결을 설정하겠다는 의미입니다. ACK 메시지에는 클라이언트의 ISN에 1을 더한 숫자가 포함됩니다. 이는 서버가 데이터를 전송하기 위한 다음 순차 번호를 의미합니다.
3. 클라이언트는 서버로부터 받은 SYN/ACK 메시지에 대한 ACK 메시지를 보냅니다. 이는 클라이언트가 서버로부터 받은 메시지를 정상적으로 수신했음을 나타냅니다. 클라이언트의 ACK 메시지에는 서버의 다음 순차 번호가 포함됩니다.

TCP 연결의 3-way handshake 과정은 최초에 클라이언트와 서버가 연결을 설정할 때 수행됩니다. 이 과정에서 클라이언트가 서버에게 SYN 패킷을 보내고, 서버는 SYN/ACK 패킷을 보내고, 클라이언트가 다시 ACK 패킷을 보내는 방식으로 연결이 설정됩니다. 이후에는 데이터 전송을 위해 연결 설정 과정을 반복할 필요가 없습니다.

데이터 전송 중에는, 연결이 이미 설정되어 있기 때문에 3-way handshake 과정을 반복하지 않습니다. 대신 데이터 전송에 따라서 패킷을 보내고, ACK 패킷을 받는 등의 과정이 반복됩니다.

 

TCP에서 4-way handshake는 TCP 연결 해제를 수행하는 방법입니다. 이 과정에서 클라이언트와 서버 간에 네 개의 메시지가 교환됩니다.

1. 클라이언트는 연결을 종료하겠다는 FIN (Finish) 메시지를 서버에게 보냅니다.
2. 서버는 FIN 메시지를 받고, 클라이언트로부터 받은 모든 데이터를 처리한 후, ACK 메시지를 보냅니다. 이는 서버가 클라이언트로부터 받은 데이터를 모두 처리했음을 의미합니다.
3. 서버는 더 이상 보낼 데이터가 없음을 나타내는 FIN 메시지를 클라이언트에게 보냅니다.
4. 클라이언트는 FIN 메시지를 받고, ACK 메시지를 보냅니다. 이는 클라이언트가 서버로부터 받은 데이터를 모두 처리했음을 의미합니다. 이후에는 클라이언트와 서버 간의 TCP 연결이 종료됩니다.

4-way handshake는 TCP 연결 해제를 수행할 때 사용되며, 3-way handshake와 같이 상호작용하는 메시지 교환 방식을 사용합니다.

 

Securing TCP & UDP)

 

SSL/TLS:

 

TCP는 SSL/TLS 프로토콜을 사용하여 전송되는 데이터를 암호화할 수 있습니다. SSL/TLS는 공개키 및 대칭키 암호화를 사용하여 데이터를 보호합니다.

 

SSL/TLS 프로토콜은 인터넷 상에서 데이터 전송 시 보안을 제공하기 위한 프로토콜입니다. SSL은 Secure Sockets Layer의 약자이며, TLS는 Transport Layer Security의 약자입니다. SSL/TLS는 데이터를 암호화하여 안전하게 전송하며, 데이터의 기밀성, 무결성, 인증을 보장합니다. 이 프로토콜은 공개키 암호화 및 대칭키 암호화를 사용하여 데이터를 암호화하고, 인증서를 사용하여 상대방의 신뢰성을 확인합니다. SSL/TLS는 전송 계층에서 데이터 보안을 제공하며 웹 서버와 클라이언트 사이에서 주로 사용됩니다.

 

IPsec:

 

일반적으로 UDP는 IPsec 프로토콜과 함께 사용됩니다.

 

IPsec는 인터넷 프로토콜(IP)을 사용하여 가상 사설 네트워크(VPN)를 만들고, 데이터의 기밀성, 무결성 및 인증을 보장합니다. IPsec는 가상 사설 네트워크(VPN)를 만들고, 데이터의 기밀성, 무결성 및 인증을 보장합니다. 이 프로토콜은 IP 패킷에 대한 암호화와 인증을 수행하고, 보안 협상 프로토콜인 IKE(Internet Key Exchange)를 사용하여 인증서 및 대칭키 등의 정보를 교환합니다. IPsec는 전송 모드와 터널 모드 두 가지 모드를 지원합니다. 전송 모드는 패킷 내부의 데이터를 암호화하는 반면, 터널 모드는 패킷 자체를 암호화합니다. IPsec는 네트워크 계층에서 데이터 보안을 제공하며 VPN 및 네트워크 보안에 사용됩니다.

 

 

HTTP Protocol)

 

HTTP(Hypertext Transfer Protocol) 프로토콜은 웹 상에서 클라이언트와 서버 간에 데이터를 주고받는 데 사용되는 프로토콜입니다. HTTP는 클라이언트에서 서버로 요청(Request)을 보내고, 서버에서 클라이언트로 응답(Response)을 보내는 방식으로 동작합니다.

 

 

 

 

HTTP 1.0은 초기 버전으로, 각각의 요청마다 새로운 연결을 만들었습니다. 이로 인해 많은 지연이 발생하고, 대역폭의 낭비가 있었습니다. 또한, HTTP 1.0은 캐싱 기능이 부족하여 웹 사이트의 성능이 저하되는 문제가 있었습니다.

 

HTTP 1.1은 지속적 연결(Persistent Connection)을 도입하여, 연결을 유지하고 여러 개의 요청과 응답을 동시에 처리할 수 있게 되었습니다. 또한, 파이프라인(Pipelining) 기능을 추가하여, 여러 개의 요청을 동시에 보내고 응답을 받을 수 있게 되어 성능이 향상되었습니다. 또한, 캐싱 기능이 개선되어 불필요한 데이터 전송을 방지할 수 있게 되었습니다.

 

HTTP 2.0은 지속적 연결과 파이프라이닝 기능을 보다 개선하여, 성능이 더욱 향상되었습니다. 또한, 멀티플렉싱(Multiplexing) 기능을 도입하여, 하나의 연결에서 여러 개의 요청과 응답을 동시에 처리할 수 있게 되었습니다. 또한, 서버 푸시(Server Push) 기능을 도입하여, 클라이언트의 요청 없이 서버에서 필요한 리소스를 미리 보내는 기능을 추가하였습니다.

 

HTTP는 비상태(Stateless) 프로토콜로, 각각의 요청과 응답이 독립적이며, 이전 요청과 응답에 대한 정보를 유지하지 않습니다. 이러한 특징은 다음과 같은 장단점을 가지고 있습니다.

 

장점:

1. 서버에 대한 부담이 적습니다: HTTP는 각각의 요청과 응답이 독립적이기 때문에, 서버에서는 클라이언트 간의 상태 정보를 유지할 필요가 없습니다. 이로 인해 서버의 부담이 적어지고, 더 많은 클라이언트 요청을 처리할 수 있게 됩니다.
2. 분산 환경에 적합합니다: HTTP는 각각의 요청과 응답이 독립적이기 때문에, 여러 대의 서버에서 처리할 수 있습니다. 이러한 특징은 분산 환경에서 동작하는 웹 애플리케이션에 적합합니다.
3. 캐싱을 이용한 성능 향상이 가능합니다: HTTP는 비상태 프로토콜이기 때문에, 캐싱 기능을 이용하여 불필요한 데이터 전송을 방지할 수 있습니다. 이는 웹 사이트의 성능을 향상시키는데 큰 역할을 합니다.

단점:

1. 상태 정보를 유지하지 않기 때문에, 이전 요청과 응답에 대한 정보를 유지할 수 없습니다. 따라서, 클라이언트가 이전 요청에서 전달한 정보를 다음 요청에서 다시 전달해야 하는 경우가 있습니다.
2. 보안에 취약합니다: HTTP는 비암호화된 프로토콜이기 때문에, 보안에 취약합니다. 이러한 문제를 해결하기 위해서는 HTTPS와 같은 보안 프로토콜을 사용해야 합니다.
3. 대용량 데이터 전송에 취약합니다: HTTP는 대용량 데이터 전송에 취약합니다. 이는 HTTP가 TCP를 기반으로 동작하기 때문에, TCP의 특성상 대용량 데이터를 한 번에 전송하기 어렵기 때문입니다.
4. 인증과 인가가 부족합니다: HTTP는 인증과 인가 기능이 부족합니다. 이러한 문제를 해결하기 위해서는 보안 프로토콜을 사용해야 합니다.
5. 느린 속도: HTTP는 각각의 요청과 응답마다 연결을 맺고 끊어야 하기 때문에, 연결 시간이 추가됩니다. 따라서, 대량의 작은 파일을 전송하는 경우에는 속도가 느릴 수 있습니다.

 

HTTP는 TCP를 기반으로 동작합니다. TCP는 연결 지향적인 프로토콜로, 데이터의 정확성과 신뢰성을 보장합니다. 또한, TCP는 흐름 제어와 혼잡 제어 기능을 제공하여 대역폭의 효율적인 관리가 가능합니다.

 

RTT)

 

RTT (Round Trip Time)는 데이터가 송수신되는 데 걸리는 시간을 의미합니다. 일반적으로, 송신자가 데이터를 보내고 수신자가 해당 데이터를 받아서 송신자에게 응답을 보내는 데까지 걸리는 시간을 측정합니다. 이러한 RTT는 네트워크의 지연 시간을 나타내며, 네트워크 성능을 평가하는 데 중요한 지표 중 하나입니다.

 

 

HTTP에서 RTT는 매우 중요한 요소입니다. HTTP는 각각의 요청마다 연결을 맺고 끊어야 하기 때문에, 각각의 요청에 대해 RTT가 발생합니다. 따라서, HTTP에서 RTT는 성능에 큰 영향을 미칩니다. 대부분의 웹 페이지는 여러 개의 리소스 (이미지, 스타일 시트, 자바스크립트 파일 등)를 포함하고 있으며, 각각의 리소스는 HTTP 요청을 통해 가져옵니다. 이러한 요청에 대해 RTT가 발생하므로, HTTP에서는 대량의 리소스를 가져올 때 성능 문제가 발생할 수 있습니다.

 

 

 

HTTP 1.0)

 

HTTP 1.0 요청을 보내기 위해서는 TCP 연결이 필요합니다. TCP는 신뢰성이 높은 연결 지향 프로토콜이므로, 연결을 설정하는 데에도 RTT가 발생합니다.

 

1. 클라이언트는 서버와 TCP 연결을 설정하기 위해 3-way handshake를 수행합니다. 이 과정에서는 클라이언트가 서버에게 SYN 패킷을 보내고, 서버는 SYN/ACK 패킷을 보내고, 클라이언트는 ACK 패킷을 보내서 연결을 설정합니다. 이 과정에서 3RTT가 발생하므로, 최소 3번의 RTT가 발생합니다.

 

2. 클라이언트는 HTTP 요청을 서버로 보냅니다. 이 과정에서도 최소 1번의 RTT가 발생합니다. 클라이언트는 요청을 보낼 때, 서버의 IP 주소와 포트 번호를 사용하여 TCP 세그먼트를 생성합니다. 이 세그먼트는 IP 패킷으로 캡슐화되어 인터넷 상에서 전송됩니다.

 

3. 서버는 요청을 받고, 요청에 대한 응답을 생성합니다. 이 과정에서도 최소 1번의 RTT가 발생합니다. 서버는 응답을 생성한 후, 이를 TCP 세그먼트로 캡슐화하여 클라이언트로 전송합니다. 따라서, HTTP 요청을 처리하기 위해서는 최소 2번의 RTT가 발생하며, 이는 HTTP의 성능에 큰 영향을 미칩니다.

 

이러한 문제를 해결하기 위해서는 HTTP Keep-Alive와 같은 기술을 사용하여 여러 개의 요청과 응답을 하나의 연결에서 처리할 수 있습니다. 또한, HTTP/2와 같은 새로운 버전의 프로토콜은 요청과 응답을 하나의 연결에서 처리하며, 다중화 기능을 제공하여 RTT를 최소화합니다.

 

HTTP 1.1 이후)

 

Persistent HTTP는 여러 개의 요청과 응답을 하나의 TCP 연결에 모아서 처리하는 방식입니다.

이 방식은 HTTP 요청을 처리하기 위한 TCP 연결 설정 과정을 최초 1회만 수행하면 되므로, 3-way handshake 과정에서 발생하는 최소 1회의 RTT를 절약할 수 있습니다. 또한, 여러 개의 요청과 응답을 하나의 TCP 연결에 모아서 처리하기 때문에, 연결 설정 비용이 줄어들어서 TCP 연결의 수도 감소시킬 수 있습니다.

 

따라서, Persistent HTTP는 RTT 측면에서 유리한 점이 있습니다. 하지만, HTTP/1.1에서는 Pipeline 방식을 사용해서 Persistent HTTP의 성능을 더욱 개선시키고 있습니다. Pipeline 방식은 클라이언트가 여러 개의 요청을 한 번에 보내고, 서버는 이를 순차적으로 처리해서 응답을 보내는 방식입니다. 이 방식은 하나의 TCP 연결을 통해 여러 개의 요청과 응답을 처리하기 때문에, RTT를 효과적으로 줄일 수 있습니다.

 

HTTP Method Types)

 

HTTP 1.0과 1.1 이후의 Method Types는 다음과 같습니다.

 

HTTP 1.0 Method Types

• GET: 지정한 리소스의 표시를 요청합니다.
• HEAD: GET과 동일한 기능을 수행하지만, 응답 본문(body)을 포함하지 않습니다.
• POST: 지정한 리소스에 엔티티를 제출합니다.
• PUT: 지정한 위치에 엔티티를 저장합니다.
• DELETE: 지정한 리소스를 삭제합니다.
• LINK: 특정 리소스와의 링크를 생성합니다.
• UNLINK: 특정 리소스와의 링크를 제거합니다.

HTTP 1.1 Method Types

• GET
• HEAD
• POST
• PUT
• DELETE
• CONNECT: 지정한 리소스로의 터널을 설정합니다.
• OPTIONS: 지정한 리소스가 제공하는 메소드 등의 정보를 조회합니다.
• TRACE: 클라이언트 요청이 서버에 의해 수신되는 경로를 반환합니다.
• PATCH: 지정한 리소스의 일부를 수정합니다.

HTTP 1.1 이후의 Method Types에서는 CONNECT, OPTIONS, TRACE, PATCH 메소드가 추가되었습니다.

 

CONNECT 메소드는 프록시 서버와 함께 사용되어 SSL 터널링을 설정하는 데 사용됩니다.

OPTIONS 메소드는 지정한 리소스가 지원하는 메소드 등의 정보를 조회하는 데 사용됩니다.

TRACE 메소드는 클라이언트 요청이 서버에 의해 수신되는 경로를 반환하는 데 사용됩니다.

PATCH 메소드는 PUT 메소드와 유사하지만, 지정한 리소스의 일부분만 수정할 수 있습니다.

 

 

PUT 메소드의 위험성)

 

PUT 메소드는 HTTP 요청을 통해 데이터를 서버에 업로드하는 메소드로, PUT 요청을 보내면 서버에서 해당 위치에 새로운 데이터를 업로드하거나, 기존 데이터를 덮어쓰게 됩니다. 이 때문에 PUT 메소드는 일부분의 위험성을 내포하고 있습니다.

만약 PUT 요청을 처리하는 서버 측에서 적절한 보안 검증이 이루어지지 않는다면, 악의적인 사용자가 PUT 요청을 이용하여 서버의 기밀 정보를 노출시키거나, 중요한 데이터를 삭제하거나 덮어쓸 수 있습니다. 이러한 보안 위협을 예방하기 위해서는, PUT 요청을 처리하는 서버 측에서 적절한 인증과 권한 검사를 수행해야 합니다.

따라서, PUT 메소드를 사용할 때에는 보안 검증과 권한 검사 등 적절한 보안 조치가 반드시 이루어져야 하며, 민감한 데이터를 업로드하는 경우에는 HTTPS와 같은 보안 프로토콜을 사용하여 데이터 전송을 암호화해야 합니다.

 

HTTP Method Types는 웹 어플리케이션에서 데이터를 요청하고, 처리하고, 수정하고, 삭제하기 위한 기능들을 정의하는 중요한 요소입니다.

 

 

클라이언트 TO SERVER)

 

HTTP 요청 메소드 중 POST 메소드와 URL 인코딩 방식은 서로 다른 개념입니다. POST 메소드는 HTTP 요청 메소드 중 하나로, 서버로 데이터를 전송하기 위한 메소드입니다. 반면 URL 인코딩 방식은 데이터를 URL에 포함시키기 위한 방법 중 하나입니다.

 

POST 메소드를 사용하여 데이터를 전송하는 경우에는 HTTP 요청 본문에 데이터를 담아서 서버로 전송하게 됩니다. 이를테면, 사용자가 입력한 내용을 서버로 전송하거나, 새로운 리소스를 생성하기 위한 데이터를 전송할 때 주로 사용됩니다.

 

URL 인코딩 방식은 데이터를 URL 문자열에 포함시키기 위한 방법 중 하나입니다. 이 방식을 사용하면, URL 내에 포함된 데이터를 서버에서 읽어서 처리할 수 있습니다. 일반적으로 웹 페이지에서는 검색어나 페이지 번호 등을 URL에 포함시키는 경우에 URL 인코딩 방식을 사용합니다.

 

HTTP response status codes)

 

HTTP response status codes는 HTTP 응답 메시지에서 서버가 클라이언트에게 전달하는 세 자리 숫자로, 요청이 성공적으로 처리되었는지, 오류가 발생했는지, 클라이언트가 추가 조치를 취해야 하는지 등을 나타냅니다.

 

상태 코드는 세 자리 숫자로 이루어져 있으며, 각각의 숫자 그룹은 상태를 표시하는 데 사용됩니다.

첫 번째 숫자 그룹은 요청의 성공 또는 실패를 나타내며,

두 번째 숫자 그룹은 클라이언트의 오류를 나타내고,

세 번째 숫자 그룹은 서버의 오류를 나타냅니다.

 

 

 

Cookie)

 

쿠키(Cookie)는 웹 사이트가 사용자의 브라우저에 저장하는 작은 텍스트 파일로, 인증, 세션 관리, 개인화 등 다양한 용도로 사용됩니다. 쿠키는 클라이언트 측에서 생성되어 웹 서버에 전송되며, 이를 통해 웹 사이트는 사용자를 구별하고 사용자에 대한 정보를 유지할 수 있습니다.

쿠키는 크게 네 가지 구성 요소를 갖습니다.

1. Name: 쿠키의 이름입니다.
2. Value: 쿠키의 값입니다.
3. Expires/Max-Age: 쿠키의 만료 시간입니다. 만료 시간이 지나면 더 이상 사용할 수 없습니다.
4. Domain/Path: 쿠키의 유효 도메인 또는 경로입니다. 이를 통해 쿠키가 전송될 도메인이나 경로를 제한할 수 있습니다.

예를 들어, 쇼핑몰에서 쿠키를 사용하는 경우, 사용자의 로그인 정보를 저장하거나 장바구니에 추가한 상품 정보를 저장할 수 있습니다. 이를 위해, 쿠키 이름으로는 'user_id', 'cart_items' 등이 사용될 수 있고, 쿠키 값으로는 실제 사용자 ID나 장바구니에 추가한 상품의 ID 등이 사용될 수 있습니다. 만료 시간은 사용자가 로그인한 후 일정 시간 동안 유지될 수 있도록 설정될 수 있습니다. 유효 도메인이나 경로는 쿠키가 전송될 도메인이나 경로를 제한하는 데 사용됩니다.

 

쿠키는 보안에 취약한 부분이 있어서, 개인 정보가 포함된 쿠키가 탈취될 경우 보안에 문제가 발생할 수 있습니다. 따라서, 보안이 중요한 사이트의 경우에는 쿠키의 사용을 최소화하거나 보안 강화를 위해 HTTPS 프로토콜을 사용해야 합니다.