HHyo814
발행일

[ZBF] 9주차 관련 네트워크

기술노트네트워크

[ZBF] 9주차 관련 네트워크

이 글은 네이버 블로그에 2024년 8월 4일에 올렸던 것을 그대로 옮겨온 것입니다.

  1. TCP

송신부와 수신부의 연결을 확인 하는 연결형 서비스

패킷이 전달 되는 회선이 정해져 있는 가상 회선 패킷 교환 방식 사용

데이터 손실이 없음을 보장하므로 신뢰성이 높음

연결 할때는 3way 핸드 쉐이킹, 해제 할때에는 4way 핸드 세이킹을 함

신뢰성 보장 방법

흐름 제어 : 수신부와 송신부간 데이터 처리 속도 제어

혼잡제어: 송신부의 데이터 전달 속도와 네트워크 속도 차이 해결

오류 제어 : 데이터의 오류 검출 및 재전송

  1. UDP

송신부와 수신부의 연결이 보장되지 않는 비연결형 서비스

패킷이 서로 다른 회선으로 교환 될 수 있는 데이터 그램 패킷 교환 방식 사용

데이터 신뢰성이 낮음

체크섬 필드를 이용해 최소한의 오류 검출 가능

  1. HTTP

인터넷에서 데이터를 전송하기 위한 클라이언트-서버 구조의 통신 프로토콜

비연결성 : 서버에서 응답을 받으면 연결을 끊음

무상태 : 서버가 클라이언트를 식별하지 못함

쿠키와 세션을 통해 비연결성과 무상태의 단점 보완

쿠키 : 클라이언트 로컬에 저장되는 키와 값이 들어있는 작은 데이터 파일

세션 : 서버에 저장되는 연결 관련 정보

  1. HTTPS

SSL/TLS를 이용해 HTTP의 보안을 강화한 웹 통신 프로토콜

SSL은 전송 계층과 응용 계층 사이에 있는 보안을 위한 통신 계층

  1. TCP Keep Alive 와 HTTP Keep Alive

TCP Keep Alive: 연결된 세션을 계속 유지하기 위한 방식 . 일정 시간 동안 패킷 교환이 없으면 연결 유지 여부를 확인하는 패킷을 던짐

HTTP Keep Alive:일정 시간 동안 연결을 유지하는 방식, 정해진 시간이 끝나면 연결 해제

  1. REST

URL로 자원을 명시하고 HTTP 메서드로 CRUD 를 연산하는 소프트웨어 아키텍처

HTTP 프로토콜을 사용하므로 별도 인프라를 구축할 필요가 없음

HTTP 프로토콜을 따르는 모든 플랫폼에서 사용 할 수 있음

사용 가능한 메서드가 한정적이라는 단점이 있음

구성 요소

자원 : URL을 이용해 클라이언트에서 서버로 지원 조작을 요청할 수 있음

행위 : HTTP 메서드로 자원에 대한 연산을 수행하게 함

표현 : JSON 또는 XML로 데이터를 주고 받음.

  1. HTTP 메서드

POST : CREATE 연산 . 데이터를 생성할 때 사용

GET : READ 연산. 서버에서 데이터를 조회할 때 사용

PUT : UPDATE 연산. 데이터를 갱신 할 때 사용

DELETE : DELETE 연산 . 데이터를 제거 할 때 사용

1.TCP의 특징을 설명해 보세요.

TCP의 주요 특징:

  1. 신뢰성 있는 데이터 전송:

  • TCP는 데이터가 올바르게 전달되었는지 확인하기 위해 **확인 응답(ACK, Acknowledgment)**을 사용합니다. 수신자가 데이터를 받으면 송신자에게 성공적으로 수신했음을 알리는 ACK 패킷을 보냅니다.

  • 만약 데이터가 손실되거나 손상되었다면, 송신자는 재전송을 통해 해당 데이터를 다시 전송합니다. 이를 통해 데이터 전송의 신뢰성을 보장합니다.

  1. 데이터 흐름 제어(Flow Control):
  • TCP는 네트워크의 혼잡을 방지하기 위해 송신 속도를 조절합니다. 수신자가 처리할 수 있는 데이터의 양을 고려하여 데이터를 송신함으로써 네트워크가 과부하 상태에 빠지지 않도록 합니다. 이를 위해 슬라이딩 윈도우(sliding window) 기법을 사용합니다.
  1. 혼잡 제어(Congestion Control):
  • TCP는 네트워크의 혼잡 상태를 탐지하고 이에 따라 데이터 전송 속도를 조절합니다. 혼잡 상태가 감지되면 데이터 전송 속도를 줄여 네트워크 과부하를 방지합니다. 대표적인 혼잡 제어 알고리즘으로 AIMD(Additive Increase Multiplicative Decrease), Slow Start, Fast Retransmit, Fast Recovery 등이 있습니다.
  1. 세그먼트화 및 순서 보장:
  • TCP는 데이터를 작은 단위인 **세그먼트(segment)**로 나누어 전송합니다. 각 세그먼트에는 순서 번호가 포함되어 있어, 수신자는 데이터를 원래 순서대로 재조립할 수 있습니다. 이를 통해 순서 보장을 제공합니다.
  1. 연결 지향적 프로토콜:
  • TCP는 통신을 시작하기 전에 송신자와 수신자 간에 3-way handshake라는 절차를 통해 연결을 설정합니다. 연결이 설정된 후에 데이터 전송이 시작되며, 통신이 끝나면 연결을 종료합니다. 이를 통해 연결 지향적(connected-oriented) 통신을 제공합니다.
  1. 오류 검출:
  • TCP는 데이터 전송 중에 발생할 수 있는 오류를 검출하기 위해 **체크섬(checksum)**을 사용합니다. 체크섬은 데이터의 무결성을 확인하는 데 사용되며, 오류가 검출되면 해당 세그먼트를 재전송합니다.
  1. TCP의 연결 및 해제 과정을 설명해보세요.

TCP 연결 과정 (3-Way Handshake)

TCP 연결은 3-way handshake라는 과정을 통해 설정됩니다. 이 과정은 송신자와 수신자 간의 연결을 성립하고, 양측이 서로의 존재를 확인하여 신뢰성 있는 데이터 전송을 준비하는 데 사용됩니다.

  1. SYN (Synchronize):

  • 송신자가 연결 요청을 시작합니다. 이를 위해 송신자는 SYN 플래그가 설정된 패킷을 수신자에게 보냅니다. 이 패킷에는 초기 순서 번호(Initial Sequence Number, ISN)가 포함되어 있습니다.

  • 이 단계에서는 수신자에게 "연결을 시작하겠다"는 의사를 전달합니다.

  1. SYN-ACK (Synchronize-Acknowledgment):

  • 수신자는 송신자로부터 SYN 패킷을 수신하면, 이를 수락한다는 의미로 SYN-ACK 패킷을 송신자에게 보냅니다.

  • 이 패킷에는 수신자의 초기 순서 번호와 송신자의 SYN 패킷에 대한 **확인 응답(ACK)**이 포함되어 있습니다.

  1. ACK (Acknowledgment):

  • 송신자는 수신자로부터 SYN-ACK 패킷을 수신하면, 연결 설정이 완료되었음을 알리는 ACK 패킷을 수신자에게 보냅니다.

  • 이제 양측 간의 연결이 성립되어 데이터 전송이 가능해집니다.

이 과정을 통해 양측은 서로의 존재와 초기 상태를 확인하며, 데이터 전송을 위한 연결을 안정적으로 설정합니다.

TCP 연결 해제 과정 (4-Way Handshake)

TCP 연결 해제는 4-way handshake라는 과정을 통해 수행됩니다. 이 과정은 양측이 데이터를 모두 전송한 후 연결을 종료하기 위해 사용됩니다.

  1. FIN (Finish):
  • 송신자가 연결을 종료하려면 FIN 플래그가 설정된 패킷을 수신자에게 보냅니다. 이는 "더 이상 보낼 데이터가 없다"는 것을 의미합니다.
  1. ACK (Acknowledgment):

  • 수신자는 송신자로부터 FIN 패킷을 수신하면, 해당 패킷에 대한 **확인 응답(ACK)**을 송신자에게 보냅니다.

  • 이 단계에서 수신자는 아직 데이터를 전송할 수 있으며, 연결이 즉시 종료되지는 않습니다.

  1. FIN (Finish):
  • 수신자도 더 이상 전송할 데이터가 없으면 FIN 패킷을 송신자에게 보냅니다. 이는 수신자가 데이터 전송을 종료하겠다는 의미입니다.
  1. ACK (Acknowledgment):

  • 송신자는 수신자로부터 FIN 패킷을 수신한 후, 이에 대한 **확인 응답(ACK)**을 수신자에게 보냅니다.

  • 이 마지막 ACK 패킷 전송 후, 연결은 완전히 종료됩니다.

이 과정을 통해 TCP는 연결 해제를 안정적으로 수행하며, 양측은 모두 데이터 전송이 완료되었음을 인지합니다. 이러한 단계적인 연결 종료 과정은 데이터 유실을 방지하고, 모든 데이터가 성공적으로 전송되었음을 보장합니다.

추가적인 고려사항:

  • TIME_WAIT: 송신자는 마지막 ACK를 보낸 후, 일정 시간 동안 TIME_WAIT 상태에 머물러 추가적인 패킷이 도착할 가능성을 대비합니다. 이는 네트워크 상의 지연 문제로 인해 발생할 수 있는 잘못된 패킷을 방지합니다.

  • 비정상적인 종료: 네트워크 장애나 시스템 오류로 인해 연결이 비정상적으로 종료될 수 있습니다. 이런 경우에는 TCP 프로토콜에 의해 자동으로 재전송되거나, 연결 재설정이 시도됩니다.

  1. TCP에서 데이터의 신뢰성을 보장하기 위한 방법을 설명해보세요.

TCP의 신뢰성을 보장하기 위한 메커니즘

  1. 데이터 세그먼트와 순서 제어

  • 데이터 세그먼트화:

  • TCP는 데이터를 **세그먼트(segment)**라는 작은 단위로 나누어 전송합니다. 각 세그먼트는 고유한 **순서 번호(Sequence Number)**를 가지며, 이를 통해 수신자는 세그먼트를 올바른 순서로 재조립할 수 있습니다.

  • 순서 번호는 데이터의 바이트 스트림을 기반으로 하여, 수신자가 데이터를 순서대로 수신했는지 확인할 수 있도록 돕습니다.

  1. 오류 검출 및 수정

  • 체크섬(Checksum):

  • TCP는 각 세그먼트에 대해 체크섬을 계산하여 데이터의 무결성을 검증합니다. 송신자는 데이터 세그먼트를 전송할 때 체크섬을 함께 전송하며, 수신자는 이 체크섬을 사용하여 데이터가 전송 중 손상되었는지 확인합니다.

  • 체크섬을 통해 오류가 감지되면 해당 세그먼트는 무시되고, 송신자에게 재전송 요청이 이루어집니다.

  1. 확인 응답과 재전송

  • 확인 응답(ACK):

  • 수신자는 송신자로부터 데이터를 수신할 때마다 해당 세그먼트에 대한 **확인 응답(ACK)**을 송신자에게 보냅니다. 이를 통해 송신자는 데이터가 성공적으로 전송되었음을 확인할 수 있습니다.

  • 송신자가 일정 시간 내에 ACK를 받지 못하면, 해당 세그먼트를 재전송합니다.

  • 재전송 메커니즘:

  • TCP는 타이머를 사용하여 특정 시간 내에 ACK를 수신하지 못한 세그먼트를 자동으로 재전송합니다. 이 타이머는 네트워크 상황에 따라 적응적으로 조정됩니다.

  • 빠른 재전송(Fast Retransmit): 수신자가 연속된 세그먼트를 받지 못한 경우 중복 ACK를 송신자에게 보내며, 송신자는 중복된 ACK를 세 번 받으면 해당 세그먼트를 재전송합니다.

  1. 흐름 제어(Flow Control)

  • 슬라이딩 윈도우(Sliding Window):

  • TCP는 슬라이딩 윈도우 메커니즘을 통해 송신자와 수신자 간의 데이터 전송 속도를 조절합니다. 수신자가 처리할 수 있는 데이터 양을 지정하여 송신자가 이를 초과하는 데이터를 전송하지 않도록 합니다.

  • 수신자는 자신이 처리할 수 있는 데이터 양을 **윈도우 크기(Window Size)**로 송신자에게 알립니다. 송신자는 이 윈도우 크기 내에서만 데이터를 전송합니다.

  1. 혼잡 제어(Congestion Control)

  • 혼잡 제어 알고리즘:

  • TCP는 네트워크 혼잡을 방지하기 위해 여러 혼잡 제어 알고리즘을 사용합니다. 대표적인 알고리즘에는 Slow Start, Congestion Avoidance, Fast Recovery 등이 있습니다.

  • 혼잡 제어는 네트워크의 혼잡 상태를 탐지하고, 이에 따라 데이터 전송 속도를 조절하여 네트워크의 효율성을 유지합니다.

  • 네트워크 상태 모니터링:

  • TCP는 혼잡 제어를 위해 네트워크의 상태를 모니터링하며, 패킷 손실이나 지연을 감지하면 송신 속도를 조정합니다. 이를 통해 네트워크가 과부하 상태에 빠지지 않도록 합니다.

  1. UDP의 특징을 설명해보세요.

UDP(User Datagram Protocol)는 TCP와 함께 가장 널리 사용되는 전송 계층 프로토콜 중 하나입니다. UDP는 간단하고 효율적인 방식으로 데이터를 전송하며, TCP와는 다른 몇 가지 독특한 특징을 가지고 있습니다.

UDP의 주요 특징

  1. 비연결형 프로토콜 (Connectionless Protocol)

  • UDP는 비연결형 프로토콜로, 데이터를 전송하기 전에 송신자와 수신자 간에 연결을 설정하지 않습니다.

  • 이로 인해 UDP는 TCP보다 초기 설정 시간이 짧고, 오버헤드가 적습니다.

  1. 데이터그램 기반 (Datagram-Oriented)

  • UDP는 데이터를 데이터그램(datagram) 단위로 전송합니다. 각 데이터그램은 독립적으로 처리되며, 데이터그램이 전송되는 경로는 네트워크 상황에 따라 달라질 수 있습니다.

  • 데이터그램은 별도의 순서 번호 없이 전송되기 때문에, 수신자는 데이터그램을 수신한 순서대로 처리해야 합니다.

  1. 신뢰성 없는 전송 (Unreliable Transmission)

  • UDP는 데이터 전송의 신뢰성을 보장하지 않습니다. 즉, 데이터그램이 전송 중에 손실되거나 손상되더라도 이를 감지하거나 재전송하지 않습니다.

  • 이러한 특성은 빠른 전송이 필요한 애플리케이션에 적합하며, 데이터의 손실이 중요한 문제가 되지 않는 경우에 사용됩니다.

  1. 오류 검출

  • UDP는 각 데이터그램에 대해 **체크섬(checksum)**을 사용하여 오류를 검출합니다. 체크섬은 데이터그램의 무결성을 확인하는 데 사용되며, 수신자는 체크섬을 통해 데이터가 손상되었는지 확인할 수 있습니다.

  • UDP는 오류를 검출할 수 있지만, 이를 수정하거나 재전송하지는 않습니다.

  1. 빠른 전송 속도 및 낮은 지연

  • UDP는 연결 설정 없이 데이터를 전송하므로 TCP보다 빠른 전송 속도와 **낮은 지연(latency)**을 제공합니다. 이는 실시간 애플리케이션에 적합합니다.

  • 오버헤드가 적고, 연결 설정과 유지에 필요한 추가 패킷이 없으므로 네트워크 자원을 효율적으로 사용할 수 있습니다.

  1. 애플리케이션 계층의 책임 증가

  • UDP는 전송 계층에서 신뢰성을 보장하지 않기 때문에, 신뢰성 있는 통신이 필요한 경우 애플리케이션 계층에서 이를 구현해야 합니다.

  • 예를 들어, 실시간 스트리밍이나 온라인 게임과 같은 애플리케이션은 데이터 손실을 감지하고 이를 처리하기 위한 자체적인 메커니즘을 구현할 수 있습니다.

  1. 브로드캐스트 및 멀티캐스트 지원

  • UDP는 브로드캐스트와 멀티캐스트 통신을 지원합니다. 이를 통해 하나의 데이터그램을 여러 수신자에게 동시에 전송할 수 있습니다.

  • 이러한 특성은 IP 전화, 비디오 스트리밍 등에서 여러 수신자에게 동시에 데이터를 전달할 때 유용합니다.

UDP의 사용 사례

UDP는 신속한 데이터 전송이 필요하거나, 약간의 데이터 손실이 큰 문제가 되지 않는 경우에 널리 사용됩니다. UDP가 사용되는 대표적인 사례는 다음과 같습니다:

  • 실시간 스트리밍: 비디오 스트리밍, 인터넷 라디오 등에서 빠른 전송이 필요합니다.

  • 온라인 게임: 게임의 빠른 반응을 위해 UDP를 사용하여 위치 정보나 상태 업데이트를 전송합니다.

  • VoIP (Voice over IP): 음성 통신에서는 약간의 데이터 손실이 허용되며, 빠른 전송이 중요합니다.

  • DNS (Domain Name System) 쿼리: 짧은 요청-응답 시간이 요구되며, 손실된 쿼리는 클라이언트에 의해 재전송됩니다.

이처럼 UDP는 TCP에 비해 신뢰성은 낮지만, 빠른 전송과 효율성을 제공하는 장점을 가지고 있습니다. 이를 통해 다양한 애플리케이션에서 UDP의 특성을 활용할 수 있습니다.

  1. TCP와 UDP의 차이점을 설명해 보세요.

TCP와 UDP의 차이점

1. 연결 지향 vs 비연결 지향

  • TCP (연결 지향 프로토콜)

  • TCP는 연결 지향적입니다. 송신자와 수신자 간에 데이터를 전송하기 전에 3-way handshake 과정을 통해 연결을 설정합니다.

  • 이 연결은 데이터 전송이 끝날 때까지 유지되며, 연결 해제를 위한 4-way handshake를 통해 종료됩니다.

  • UDP (비연결 지향 프로토콜)

  • UDP는 비연결형입니다. 데이터를 전송하기 전에 별도의 연결 설정 과정이 없습니다.

  • 각 데이터그램은 독립적으로 전송되며, 수신자는 송신자와 연결 상태를 유지하지 않습니다.

2. 신뢰성

  • TCP

  • TCP는 신뢰성 있는 데이터 전송을 보장합니다. **확인 응답(ACK)**을 통해 송신자는 데이터가 성공적으로 전송되었는지 확인할 수 있습니다.

  • 손실된 데이터는 자동으로 재전송되며, 데이터가 순서대로 수신되도록 보장합니다.

  • 오류 검출 및 수정 기능을 통해 데이터 무결성을 유지합니다.

  • UDP

  • UDP는 신뢰성을 보장하지 않습니다. 데이터그램이 손실되거나 손상되더라도 이를 감지하거나 수정하지 않습니다.

  • 데이터가 순서대로 수신되지 않을 수 있으며, 수신자가 데이터 손실을 처리해야 합니다.

3. 데이터 전송 방식

  • TCP

  • TCP는 바이트 스트림 전송을 사용하여 데이터를 연속적인 바이트 흐름으로 전송합니다.

  • 데이터는 세그먼트 단위로 전송되며, 각 세그먼트는 순서 번호를 가지고 있어 수신자가 데이터를 올바르게 재조립할 수 있습니다.

  • UDP

  • UDP는 데이터그램 전송을 사용합니다. 각 데이터그램은 독립적으로 전송되며, 순서 번호가 없습니다.

  • 데이터그램은 크기가 고정되어 있으며, 수신자는 전송 순서를 보장받지 못합니다.

4. 오버헤드 및 전송 속도

  • TCP

  • TCP는 신뢰성을 보장하기 위한 추가적인 제어 정보를 전송해야 하므로, 오버헤드가 큽니다.

  • 연결 설정 및 종료 과정이 포함되며, 데이터 전송 중 ACK 및 재전송으로 인해 전송 속도가 상대적으로 느립니다.

  • UDP

  • UDP는 오버헤드가 적어 전송 속도가 빠릅니다. 데이터 전송에 필요한 최소한의 제어 정보를 포함합니다.

  • 연결 설정이 없고, 데이터를 즉시 전송할 수 있으므로 지연(latency)이 적습니다.

5. 흐름 제어 및 혼잡 제어

  • TCP

  • TCP는 **흐름 제어(Flow Control)**와 혼잡 제어(Congestion Control) 메커니즘을 사용하여 네트워크의 효율성을 유지합니다.

  • 슬라이딩 윈도우 및 혼잡 제어 알고리즘을 통해 데이터 전송 속도를 조절합니다.

  • UDP

  • UDP는 흐름 제어나 혼잡 제어를 제공하지 않습니다. 송신자는 데이터를 수신자의 상태와 상관없이 전송합니다.

  • 네트워크 혼잡 상황을 고려하지 않고, 수신자가 처리할 수 있는 양을 초과할 수 있습니다.

6. 사용 사례

  • TCP

  • TCP는 신뢰성이 중요한 애플리케이션에 적합합니다. 예를 들어, 웹 브라우징(HTTP), 이메일 전송(SMTP), 파일 전송(FTP) 등에 사용됩니다.

  • 데이터의 정확성과 무결성이 중요한 경우에 주로 사용됩니다.

  • UDP

  • UDP는 빠른 전송이 필요한 실시간 애플리케이션에 적합합니다. 예를 들어, 비디오 스트리밍, 온라인 게임, VoIP(Voice over IP) 등에 사용됩니다.

  • 약간의 데이터 손실이 허용될 수 있고, 낮은 지연이 중요한 경우에 주로 사용됩니다.

이처럼 TCP와 UDP는 각각의 특성에 맞는 다양한 용도로 사용됩니다. 신뢰성과 데이터 무결성이 중요한 경우에는 TCP를, 속도가 중요하고 약간의 데이터 손실이 허용될 수 있는 경우에는 UDP를 선택하는 것이 일반적입니다.

  1. UDP 에서 오류 검출 방법을 설명해 보세요.

UDP의 오류 검출 방법: 체크섬

1. 체크섬의 역할

  • 체크섬은 UDP 데이터그램의 데이터 무결성을 검증하는 데 사용됩니다. 이는 송신자가 데이터그램을 전송할 때 계산하여 데이터와 함께 수신자에게 전송하는 값입니다.

  • 수신자는 수신된 데이터그램의 체크섬을 다시 계산하여 송신자와 일치하는지 확인합니다. 일치하지 않으면 데이터가 전송 중에 손상되었음을 의미합니다.

2. 체크섬 계산 방법

  • 체크섬 계산은 송신자가 UDP 데이터그램을 전송하기 전에 수행됩니다. 이 과정은 다음과 같은 단계로 이루어집니다:
  1. 데이터그램을 16비트 워드로 분할:
  • UDP 데이터그램을 16비트 워드(2바이트) 단위로 나눕니다. 만약 데이터그램의 길이가 홀수라면, 마지막 워드의 남는 바이트를 0으로 채웁니다.
  1. 워드의 합 계산:
  • 각 16비트 워드를 모두 더하여 합계를 계산합니다. 이 합이 16비트를 초과하면 상위 비트를 하위 비트에 다시 더하는 방식으로 16비트 합계를 유지합니다.
  1. 1의 보수 연산:

  • 합계의 1의 보수를 계산합니다. 1의 보수는 모든 비트를 반전시킨 값을 의미합니다.

  • 이 1의 보수 결과가 체크섬으로 사용됩니다.

3. 수신자의 체크섬 검증

  • 수신자는 체크섬 검증을 다음과 같은 단계로 수행합니다:
  1. 데이터그램 수신:
  • 수신자는 UDP 데이터그램을 수신하고, 송신자가 포함한 체크섬을 확인합니다.
  1. 데이터그램의 체크섬 재계산:
  • 수신자는 수신된 데이터그램에 대해 체크섬을 다시 계산합니다. 송신자와 동일한 방법으로 16비트 워드 합계의 1의 보수를 구합니다.
  1. 체크섬 일치 확인:
  • 송신자가 전송한 체크섬과 수신자가 계산한 체크섬을 비교합니다. 두 값이 일치하면 데이터가 무결성을 유지한 것으로 간주합니다. 만약 일치하지 않으면, 데이터그램이 손상되었다고 판단하고, 해당 데이터그램을 무시합니다.

4. 한계 및 보완

  • UDP의 체크섬은 오류 검출만 가능하며, 오류 수정은 수행하지 않습니다. 데이터그램이 손상된 경우 수신자는 이를 무시하거나 상위 계층의 애플리케이션이 이를 처리하도록 해야 합니다.

  • 체크섬 비활성화: UDP 헤더의 체크섬 필드는 선택적이며, 체크섬을 계산하지 않도록 설정할 수 있습니다. 그러나 대부분의 구현에서는 데이터 무결성을 위해 체크섬을 활성화하는 것이 일반적입니다.

  • 응용 계층의 보완: UDP는 신뢰성을 보장하지 않으므로, 신뢰성 있는 통신이 필요한 경우 응용 계층에서 추가적인 오류 감지 및 수정 메커니즘을 구현해야 합니다.

  1. HTTP에 대해 설명해 보세요.

HTTP의 주요 특징

1. 클라이언트-서버 모델

  • 클라이언트-서버 구조:

  • HTTP는 클라이언트와 서버 간의 통신을 기반으로 합니다. 클라이언트는 요청을 보내는 주체로, 주로 웹 브라우저가 그 역할을 합니다. 서버는 요청을 받아들이고, 요청에 대한 응답을 제공하는 역할을 합니다.

  • 클라이언트가 특정 리소스를 요청하면, 서버는 해당 리소스를 찾아 응답으로 반환합니다.

2. 요청-응답 프로토콜

  • 요청(Request) 메시지:

  • 클라이언트는 서버에게 요청 메시지를 보냅니다. 이 메시지는 다음과 같은 구성 요소로 이루어져 있습니다:

  • HTTP 메서드: 리소스를 다루는 방식을 지정합니다. 대표적인 메서드로는 GET, POST, PUT, DELETE, HEAD 등이 있습니다.

  • URL(Uniform Resource Locator): 요청하고자 하는 리소스의 주소를 지정합니다.

  • HTTP 버전: 사용 중인 HTTP 프로토콜의 버전을 명시합니다.

  • 헤더(Header): 요청에 대한 추가 정보를 포함합니다. 예를 들어, User-Agent는 클라이언트 소프트웨어 정보를 나타내고, Accept는 클라이언트가 지원하는 데이터 타입을 나타냅니다.

  • 본문(Body): POST나 PUT 메서드와 같이 요청과 함께 데이터를 전송해야 하는 경우 본문에 데이터를 포함할 수 있습니다.

  • 응답(Response) 메시지:

  • 서버는 클라이언트의 요청에 대한 응답 메시지를 보냅니다. 이 메시지는 다음과 같은 구성 요소로 이루어져 있습니다:

  • HTTP 상태 코드(Status Code): 요청에 대한 서버의 처리 결과를 나타냅니다. 상태 코드는 3자리 숫자로 구성되며, 대표적으로 200 OK, 404 Not Found, 500 Internal Server Error 등이 있습니다.

  • HTTP 버전: 서버가 응답에 사용한 HTTP 프로토콜의 버전을 명시합니다.

  • 헤더(Header): 응답에 대한 추가 정보를 포함합니다. 예를 들어, Content-Type은 응답의 데이터 타입을 나타내고, Content-Length는 응답 본문의 크기를 나타냅니다.

  • 본문(Body): 요청한 리소스의 데이터를 포함합니다. HTML, JSON, 이미지 파일 등 다양한 형식의 데이터를 전송할 수 있습니다.

3. 비상태성(Stateless)

  • 비상태성의 특징:

  • HTTP는 비상태성(stateless) 프로토콜입니다. 이는 각 요청이 독립적으로 처리되며, 서버는 이전 요청에 대한 정보를 유지하지 않는다는 것을 의미합니다.

  • 상태 정보를 유지하기 위해 쿠키(Cookie)와 세션(Session) 등의 기술이 사용됩니다. 쿠키는 클라이언트에 저장되는 작은 데이터 조각으로, 서버가 클라이언트의 상태를 식별하는 데 사용됩니다.

4. HTTP 메서드

  • GET: 서버에서 리소스를 요청할 때 사용합니다. 데이터 조회에 사용되며, 본문을 포함하지 않습니다.

  • POST: 서버에 데이터를 제출할 때 사용합니다. 주로 데이터 생성이나 제출에 사용되며, 본문에 데이터를 포함합니다.

  • PUT: 서버에 리소스를 업데이트할 때 사용합니다. 요청 본문에 업데이트할 데이터를 포함합니다.

  • DELETE: 서버에서 리소스를 삭제할 때 사용합니다.

  • HEAD: GET 요청과 동일한 응답을 요청하되, 본문은 제외하고 헤더만 받습니다.

5. HTTP 상태 코드

  • 1xx (정보): 요청을 처리 중이며, 추가적인 조치를 요구합니다. 예를 들어, 100 Continue는 클라이언트가 요청을 계속해야 함을 의미합니다.

  • 2xx (성공): 요청이 성공적으로 처리되었음을 나타냅니다. 예를 들어, 200 OK는 요청이 성공적으로 완료되었음을 의미합니다.

  • 3xx (리다이렉션): 클라이언트가 요청을 완료하기 위해 추가 작업이 필요함을 나타냅니다. 예를 들어, 301 Moved Permanently는 리소스가 다른 위치로 영구적으로 이동되었음을 의미합니다.

  • 4xx (클라이언트 오류): 클라이언트의 잘못된 요청을 나타냅니다. 예를 들어, 404 Not Found는 요청한 리소스를 찾을 수 없음을 의미합니다.

  • 5xx (서버 오류): 서버의 문제로 인해 요청이 처리되지 못했음을 나타냅니다. 예를 들어, 500 Internal Server Error는 서버에서 알 수 없는 오류가 발생했음을 의미합니다.

6. HTTP 버전

  • HTTP/0.9: 초기 버전으로, 단순히 HTML 페이지를 전송하기 위한 프로토콜이었습니다. 메서드나 헤더가 없었습니다.

  • HTTP/1.0: HTTP/0.9에 비해 기능이 확장되었습니다. 헤더와 다양한 메서드가 도입되었습니다.

  • HTTP/1.1: 현재 가장 널리 사용되는 버전으로, 지속 연결(Persistent Connection), 파이프라이닝(Pipelining), 호스트 헤더(Host Header) 등의 기능이 추가되었습니다.

  • HTTP/2: 성능 개선을 위해 설계된 버전으로, 멀티플렉싱(Multiplexing), 헤더 압축(Header Compression), 서버 푸시(Server Push) 등의 기능이 추가되었습니다.

  • HTTP/3: 최신 버전으로, QUIC 프로토콜을 기반으로 하여 전송 성능과 보안을 더욱 향상시켰습니다.

  1. HTTP Keep Alive와 TCP Keep Alive를 설명해보세요.

HTTP Keep-Alive

개요

HTTP Keep-Alive는 HTTP/1.1에서 도입된 기능으로, 클라이언트와 서버 간의 연결을 지속적으로 유지하여 여러 HTTP 요청을 단일 TCP 연결에서 처리할 수 있게 해주는 기술입니다. 이를 통해 연결 설정과 종료에 드는 오버헤드를 줄이고, 전송 성능을 개선합니다.

특징 및 작동 방식

  • 지속 연결 (Persistent Connection):

  • HTTP Keep-Alive는 기본적으로 클라이언트와 서버 간의 **지속 연결(persistent connection)**을 유지합니다. 이 연결은 여러 HTTP 요청과 응답을 처리할 수 있으며, 각 요청마다 새로운 연결을 설정하지 않습니다.

  • Connection 헤더:

  • HTTP 요청 및 응답의 Connection 헤더에 "Keep-Alive" 값을 설정하여 Keep-Alive 기능을 사용합니다.

  • 이점:

  • 연결 재사용: 여러 개의 HTTP 요청이 단일 TCP 연결을 재사용하기 때문에, 연결 설정 및 종료에 소요되는 시간과 리소스를 절약할 수 있습니다.

  • 네트워크 성능 향상: 연결 설정을 반복하지 않으므로, 네트워크 지연(latency)이 감소하고, 데이터 전송 속도가 빨라집니다.

  • 리소스 효율성: 서버와 클라이언트 모두 시스템 리소스를 효율적으로 사용할 수 있습니다.

  • 연결 유지 시간:

  • Keep-Alive 연결은 영구적이지 않으며, 일정 시간 동안 유휴 상태로 유지된 후에는 종료될 수 있습니다.

  • 서버는 Keep-Alive 헤더를 사용하여 연결 유지 시간(timeout)과 최대 요청 수(maximum requests)를 지정할 수 있습니다.

  • HTTP/2와 HTTP/3의 경우:

  • HTTP/2와 HTTP/3에서는 기본적으로 연결이 지속적이므로 별도의 Keep-Alive 설정이 필요하지 않습니다. 이러한 버전들은 멀티플렉싱과 연결 재사용을 통해 HTTP/1.1의 Keep-Alive 기능을 포함합니다.

TCP Keep-Alive

개요

TCP Keep-Alive는 TCP 연결을 장시간 유휴 상태에서 유지하기 위한 기술로, 네트워크의 상태를 주기적으로 확인하여 비정상적으로 끊어진 연결을 탐지하고 복구할 수 있도록 돕습니다.

특징 및 작동 방식

  • 유휴 연결 감지:

  • TCP Keep-Alive는 연결이 유휴 상태로 오래 유지될 때, 주기적으로 작은 패킷(keep-alive probe)을 전송하여 상대방이 연결을 유지하고 있는지 확인합니다.

  • 동작 원리:

  • 일정 시간 동안 데이터가 전송되지 않으면, TCP Keep-Alive 패킷을 상대방에게 전송합니다.

  • 상대방이 응답하면 연결이 살아 있음을 확인합니다. 만약 응답이 없으면, 일정 횟수 동안 재전송을 시도한 후 연결을 끊습니다.

  • 구성 가능한 파라미터:

  • TCP Keep-Alive는 보통 운영 체제의 네트워크 설정에서 조정할 수 있으며, 다음과 같은 파라미터를 설정할 수 있습니다:

  • Keep-Alive 시간(Keep-Alive Time): 첫 번째 Keep-Alive 패킷을 전송하기까지의 유휴 시간입니다. 일반적으로 기본값은 2시간입니다.

  • Keep-Alive 간격(Keep-Alive Interval): 응답이 없을 때 Keep-Alive 패킷을 다시 전송하기까지의 간격입니다. 일반적으로 기본값은 1초에서 10초 사이입니다.

  • Keep-Alive 시도 횟수(Keep-Alive Probes): 응답이 없을 때 연결을 끊기 전에 Keep-Alive 패킷을 재전송하는 최대 횟수입니다. 일반적으로 기본값은 5번입니다.

  • 이점:

  • 비정상 연결 감지: 네트워크 오류나 상대방의 시스템 오류로 인해 비정상적으로 종료된 연결을 감지할 수 있습니다.

  • 자원 회수: 유휴 연결을 감지하고 종료하여 시스템 자원을 효율적으로 관리할 수 있습니다.

  • 단점:

  • Keep-Alive 패킷 전송은 추가적인 네트워크 트래픽을 발생시킬 수 있습니다.

  • 잘못 설정된 경우, 비정상적인 연결 종료로 인해 연결이 자주 끊길 수 있습니다.

  1. 쿠키 와 세션의 차이점을 설명해 보세요.

쿠키(Cookie)

개요

  • 쿠키는 클라이언트 측에 저장되는 작은 데이터 파일로, 웹 서버가 사용자의 브라우저에 정보를 저장하고 필요할 때 이를 다시 읽어올 수 있도록 합니다.

  • 주로 사용자 식별, 세션 관리, 사용자 설정 저장, 추적 등에 사용됩니다.

특징

  • 클라이언트 측 저장:

  • 쿠키는 사용자의 웹 브라우저에 저장됩니다. 브라우저는 요청할 때마다 해당 웹 사이트에 저장된 쿠키를 서버로 전송합니다.

  • 각 쿠키는 키-값 쌍으로 이루어져 있으며, 도메인과 경로에 따라 사용 범위가 제한됩니다.

  • 유효 기간:

  • 쿠키는 생성 시 유효 기간(Expiration Date)을 설정할 수 있습니다. 이 기간이 지나면 브라우저는 해당 쿠키를 자동으로 삭제합니다.

  • 영구 쿠키(Persistent Cookie)는 유효 기간이 설정된 쿠키이며, 세션 쿠키(Session Cookie)는 브라우저가 닫힐 때 자동으로 삭제됩니다.

  • 보안:

  • 쿠키는 클라이언트 측에 저장되므로 상대적으로 보안에 취약합니다. 민감한 정보를 쿠키에 저장할 경우, 보안 문제를 초래할 수 있습니다.

  • Secure 플래그를 사용하면 쿠키가 HTTPS를 통해서만 전송되도록 할 수 있으며, HttpOnly 플래그를 사용하면 자바스크립트를 통해 쿠키 접근을 방지할 수 있습니다.

  • 크기 제한:

  • 쿠키는 일반적으로 최대 4KB 크기의 데이터를 저장할 수 있습니다. 이 제한은 각 쿠키당 적용되며, 브라우저마다 저장할 수 있는 쿠키의 총 개수에도 제한이 있을 수 있습니다.

사용 사례

  • 로그인 상태 유지: 사용자의 로그인 상태를 기억하여, 다시 로그인할 필요 없이 웹사이트를 이용할 수 있게 합니다.

  • 사용자 설정 저장: 테마, 언어 설정 등 사용자의 선호도를 저장합니다.

  • 사용자 추적 및 분석: 광고 트래킹이나 사용자 행동 분석을 위해 사용됩니다.

세션(Session)

개요

  • 세션은 서버 측에서 관리되는 데이터 저장소로, 특정 사용자와의 일시적인 상호작용 상태를 유지합니다.

  • 세션은 서버에 저장되며, 사용자가 웹 서버와의 인터랙션을 종료하거나 일정 시간이 지나면 만료됩니다.

특징

  • 서버 측 저장:

  • 세션 데이터는 서버 측에 저장됩니다. 클라이언트는 세션 ID라는 고유 식별자를 통해 서버에 저장된 세션 데이터에 접근합니다.

  • 세션 ID는 주로 쿠키를 통해 클라이언트에게 전달되지만, URL 파라미터나 숨겨진 필드로도 전달될 수 있습니다.

  • 보안:

  • 세션은 서버 측에 저장되므로, 쿠키보다 보안성이 높습니다. 민감한 정보를 안전하게 저장하고 관리할 수 있습니다.

  • 세션 하이재킹(Session Hijacking)이나 세션 고정(Session Fixation)과 같은 보안 문제를 방지하기 위해 HTTPS와 세션 관리 기법이 사용됩니다.

  • 유효 기간:

  • 세션은 일정 시간이 지나거나 사용자가 로그아웃할 때 만료됩니다. 이 유효 기간은 서버 설정에 따라 조정될 수 있습니다.

  • 세션이 만료되면, 해당 세션에 저장된 데이터는 삭제됩니다.

  • 확장성:

  • 많은 사용자를 처리하기 위해 세션은 서버의 메모리 외에도 데이터베이스나 캐시 시스템(Redis, Memcached 등)에 저장될 수 있습니다.

사용 사례

  • 사용자 인증 및 권한 관리: 사용자가 로그인한 상태를 유지하고, 사용자 권한을 관리합니다.

  • 쇼핑 카트 기능: 전자 상거래 웹사이트에서 사용자별로 장바구니 데이터를 관리합니다.

  • 사용자별 데이터 저장: 사용자의 세션 상태에 따라 맞춤형 서비스를 제공합니다.

쿠키와 세션의 협력 사용

쿠키와 세션은 종종 함께 사용됩니다. 세션을 통해 민감한 데이터를 안전하게 관리하고, 쿠키를 통해 세션 ID를 클라이언트에게 전달함으로써 사용자 경험을 개선하고 서버 리소스를 효율적으로 사용할 수 있습니다.

  1. HTTP와 HTTPS의 차이점을 설명해보세요.

HTTP와 HTTPS는 웹에서 데이터 전송을 위해 사용되는 두 가지 프로토콜로, 주된 차이점은 보안성에 있습니다. HTTPS는 HTTP의 확장 버전으로, 데이터의 기밀성과 무결성을 보장하기 위한 추가적인 보안 계층을 제공합니다.

HTTP (Hypertext Transfer Protocol)

개요

  • HTTP는 웹 클라이언트(브라우저)와 웹 서버 간의 데이터 전송을 위한 프로토콜입니다.

  • 주로 웹 페이지, 이미지, 비디오 등의 리소스를 전송하는 데 사용됩니다.

특징

  • 비암호화 전송:

  • HTTP는 데이터를 암호화하지 않고 평문으로 전송합니다. 이로 인해 데이터가 전송되는 동안 중간에서 가로채일 수 있는 위험이 있습니다.

  • 공격자는 네트워크 트래픽을 감시하여 민감한 정보를 탈취할 수 있습니다.

  • 포트 번호:

  • HTTP는 기본적으로 포트 80을 사용하여 통신합니다.

  • 보안 취약점:

  • HTTP는 중간자 공격(Man-in-the-Middle Attack), 도청(Sniffing), 데이터 변조(Tampering) 등의 보안 취약점에 노출되어 있습니다.

  • 사용 사례:

  • 보안이 필요하지 않은 정보 전송에 사용될 수 있지만, 민감한 정보를 포함한 통신에는 적합하지 않습니다.

HTTPS (Hypertext Transfer Protocol Secure)

개요

  • HTTPS는 HTTP에 보안 기능을 추가한 프로토콜로, **SSL/TLS(Secure Sockets Layer/Transport Layer Security)**를 사용하여 데이터를 암호화합니다.

  • 웹 클라이언트와 서버 간의 안전한 데이터 전송을 보장합니다.

특징

  • 암호화 전송:

  • HTTPS는 데이터를 암호화하여 전송함으로써 데이터의 기밀성을 보장합니다. 이를 통해 중간자 공격 및 도청을 방지합니다.

  • TLS/SSL을 통해 대칭키 암호화, 비대칭키 암호화, 해시 알고리즘 등이 사용됩니다.

  • 데이터 무결성:

  • HTTPS는 데이터가 전송 중에 변조되지 않도록 무결성을 보장합니다.

  • 데이터 무결성은 해시 함수를 사용하여 검증되며, 메시지 인증 코드(MAC)를 통해 추가적인 보안을 제공합니다.

  • 서버 인증:

  • HTTPS는 서버 인증을 통해 클라이언트가 통신하려는 웹 서버가 신뢰할 수 있는 서버임을 확인합니다.

  • 인증서는 인증 기관(CA)에 의해 발급되며, 클라이언트는 이 인증서를 검증하여 서버의 신뢰성을 확인합니다.

  • 포트 번호:

  • HTTPS는 기본적으로 포트 443을 사용하여 통신합니다.

  • 보안 이점:

  • HTTPS는 기밀성, 무결성, 인증을 제공하여 보안을 강화합니다. 이를 통해 민감한 데이터 전송에 적합합니다.

  • 사용 사례:

  • 금융 거래, 로그인 정보 전송, 개인 정보 보호 등 보안이 필요한 모든 웹 애플리케이션에서 사용됩니다.

HTTPS 동작 방식

  1. TLS 핸드셰이크:

  • 클라이언트와 서버 간의 연결 설정 시 TLS 핸드셰이크 과정을 통해 보안 설정을 협상합니다.

  • 클라이언트가 서버에 접속하면, 서버는 SSL/TLS 인증서를 클라이언트에게 보냅니다.

  • 클라이언트는 인증서를 검증하고, 서버와의 세션 키를 생성하여 안전한 통신을 시작합니다.

  1. 데이터 암호화:

  • 세션 키를 사용하여 클라이언트와 서버 간의 모든 데이터가 암호화되어 전송됩니다.

  • 데이터가 암호화되어 전송되므로, 중간에서 데이터를 가로채도 내용을 읽을 수 없습니다.

  1. 데이터 무결성:
  • 데이터가 전송 중에 변조되지 않았음을 보장하기 위해 해시 함수와 MAC를 사용하여 무결성을 검증합니다.
  1. 서버 인증:
  • 클라이언트는 서버의 SSL/TLS 인증서를 검증하여, 서버가 신뢰할 수 있는 주체임을 확인합니다.

HTTPS의 중요성

  • 보안성 향상: HTTPS는 HTTP에 비해 훨씬 높은 보안성을 제공합니다. 데이터 암호화, 무결성, 서버 인증을 통해 사용자 데이터를 안전하게 보호할 수 있습니다.

  • SEO 및 브라우저 지원: Google과 같은 검색 엔진은 HTTPS 웹사이트를 선호하여 검색 순위에서 유리하게 작용할 수 있습니다. 또한, 대부분의 최신 브라우저는 HTTPS를 기본으로 지원하고, HTTP 사이트에 대해 경고를 표시할 수 있습니다.

  • 신뢰성 향상: HTTPS를 사용하면 사용자는 웹사이트가 신뢰할 수 있음을 인식하며, 이는 사용자 경험과 브랜드 신뢰성을 향상시키는 데 기여합니다.

11.HTTPS에서 사용하는 암호화 방식을 설명해보세요.

HTTPS에서 사용하는 암호화 방식

1. 비대칭키 암호화 (Asymmetric Encryption)

비대칭키 암호화는 두 개의 키(공개키와 비밀키)를 사용하여 데이터를 암호화하고 복호화합니다. 이 방식은 주로 초기 연결 시 보안 채널을 설정하는 데 사용됩니다.

  • 공개키와 비밀키:

  • 공개키(Public Key): 누구나 접근할 수 있는 키로, 데이터를 암호화하는 데 사용됩니다.

  • 비밀키(Private Key): 소유자만이 접근할 수 있는 키로, 암호화된 데이터를 복호화하는 데 사용됩니다.

  • 사용 시점:

  • HTTPS에서는 클라이언트와 서버 간의 TLS 핸드셰이크 과정에서 비대칭 암호화를 사용합니다.

  • 클라이언트가 서버의 공개키를 사용하여 세션키를 암호화하여 전송하고, 서버는 비밀키로 이를 복호화합니다.

  • 주요 알고리즘:

  • RSA: 가장 널리 사용되는 비대칭 암호화 알고리즘으로, 키 교환 및 데이터 암호화에 사용됩니다.

  • ECDHE (Elliptic Curve Diffie-Hellman Ephemeral): 키 교환을 위한 알고리즘으로, 일시적인 키를 사용하여 보안을 강화합니다.

2. 대칭키 암호화 (Symmetric Encryption)

대칭키 암호화는 하나의 키를 사용하여 데이터를 암호화하고 복호화합니다. 이 방식은 데이터 전송의 기밀성을 보장하며, 비대칭 암호화보다 성능이 우수합니다.

  • 단일 키:

  • 대칭키(Symmetric Key): 동일한 키를 사용하여 데이터를 암호화하고 복호화합니다. 이 키는 TLS 핸드셰이크 과정에서 교환됩니다.

  • 사용 시점:

  • TLS 핸드셰이크 후, 클라이언트와 서버 간의 모든 데이터 전송은 대칭키 암호화를 통해 이루어집니다.

  • 주요 알고리즘:

  • AES (Advanced Encryption Standard): 현재 가장 많이 사용되는 대칭키 암호화 알고리즘으로, 보안성과 효율성이 높습니다.

  • 3DES (Triple Data Encryption Standard): 과거에 널리 사용되었으나, 현재는 AES로 대체되는 추세입니다.

3. 해시 함수 (Hash Function)

해시 함수는 입력 데이터를 고정된 크기의 해시 값으로 변환하여 데이터의 무결성을 검증하는 데 사용됩니다.

  • 데이터 무결성 검증:

  • 해시 함수는 데이터의 내용이 변조되지 않았음을 확인하는 데 사용됩니다.

  • 해시 값은 데이터 자체와는 독립적으로 계산되며, 입력 데이터의 작은 변화도 해시 값에 큰 변화를 초래합니다.

  • 주요 알고리즘:

  • SHA-256 (Secure Hash Algorithm 256-bit): 데이터 무결성을 검증하는 데 널리 사용되는 해시 알고리즘입니다.

  • HMAC (Hash-based Message Authentication Code): 메시지 인증 코드로, 해시 함수와 대칭키를 결합하여 데이터의 무결성과 인증을 동시에 보장합니다.

4. 디지털 인증서

디지털 인증서는 서버의 신원을 보증하고, 안전한 연결을 설정하기 위해 사용됩니다. HTTPS에서는 **인증 기관(CA, Certificate Authority)**이 발급한 SSL/TLS 인증서를 사용하여 서버의 신뢰성을 검증합니다.

  • 인증서 내용:

  • 공개키, 서버 정보, 인증서의 유효 기간 등이 포함되어 있습니다.

  • 검증 과정:

  • 클라이언트는 서버가 제공한 인증서를 검증하여, 해당 인증서가 신뢰할 수 있는 CA에 의해 발급되었는지 확인합니다.

  • 신뢰 체계:

  • 브라우저와 운영 체제는 신뢰할 수 있는 CA 목록을 내장하고 있으며, 인증서는 이러한 신뢰 체계를 통해 검증됩니다.

HTTPS 동작 과정

HTTPS에서 암호화 방식이 어떻게 동작하는지에 대해 TLS 핸드셰이크 과정을 통해 설명할 수 있습니다:

  1. 클라이언트 헬로 (Client Hello):
  • 클라이언트는 서버에 연결을 시도하며, 지원 가능한 암호화 알고리즘 목록과 랜덤 난수를 서버에게 전송합니다.
  1. 서버 헬로 (Server Hello):
  • 서버는 클라이언트의 요청에 응답하며, 사용할 암호화 알고리즘을 선택하고 자신의 랜덤 난수와 SSL/TLS 인증서를 클라이언트에게 전송합니다.
  1. 서버 인증서 검증:
  • 클라이언트는 서버의 인증서를 검증하여, 신뢰할 수 있는 CA에 의해 발급되었는지 확인합니다. 인증서가 유효하지 않으면 연결을 중단합니다.
  1. 프리마스터 시크릿 생성:
  • 클라이언트는 프리마스터 시크릿(premaster secret)을 생성하고, 서버의 공개키를 사용하여 암호화한 후 서버에 전송합니다.
  1. 세션키 생성:
  • 서버는 비밀키를 사용하여 프리마스터 시크릿을 복호화하고, 양측 모두 세션키를 생성하여 대칭키 암호화를 설정합니다.
  1. 핸드셰이크 완료:
  • 클라이언트와 서버는 완료 메시지를 주고받으며, 암호화된 데이터를 주고받을 준비를 마칩니다.
  1. 데이터 전송:
  • 이후의 모든 데이터 전송은 대칭키 암호화를 통해 안전하게 진행됩니다.

HTTPS의 암호화 방식의 장점

  • 기밀성: 데이터가 암호화되어 전송되므로, 중간에 데이터가 가로채어지더라도 내용을 읽을 수 없습니다.

  • 무결성: 데이터 전송 중 변조되지 않았음을 보장합니다.

  • 인증: 서버의 신뢰성을 검증하여, 사용자가 안전한 웹사이트에 접속하고 있음을 확인할 수 있습니다.

  1. 사용자가 URL을 입력한 후 화면이 출력 되기 까지의 과정을 설명해보세요.

1. URL 입력 및 처리

2. DNS 조회

  • 도메인 이름 해석:

  • 브라우저는 URL에서 도메인 이름을 추출하고, 이를 IP 주소로 변환하기 위해 DNS(Domain Name System) 조회를 수행합니다.

  • 브라우저는 우선 캐시에 저장된 DNS 정보를 확인하고, 없을 경우 로컬 DNS 서버에 쿼리를 보냅니다.

  • DNS 서버 응답:

  • DNS 서버는 해당 도메인 이름에 대한 IP 주소를 브라우저에 반환합니다.

3. TCP 연결 설정

  • 3-way Handshake:

  • 브라우저는 서버와의 연결을 위해 TCP 3-way handshake를 수행합니다. 이는 안정적인 연결을 설정하기 위한 과정입니다.

  • SYN: 브라우저가 서버에 연결 요청(SYN 패킷)을 보냅니다.

  • SYN-ACK: 서버는 연결 요청을 수락하고, 확인 응답(SYN-ACK 패킷)을 보냅니다.

  • ACK: 브라우저는 서버의 응답을 확인하고, 연결이 설정됩니다.

4. TLS 핸드셰이크 (HTTPS인 경우)

  • 보안 연결 설정:

  • HTTPS를 사용할 경우, TLS 핸드셰이크를 통해 안전한 연결을 설정합니다.

  • Client Hello: 브라우저가 지원하는 암호화 알고리즘을 서버에 제안합니다.

  • Server Hello: 서버가 사용할 암호화 알고리즘과 인증서를 브라우저에 전송합니다.

  • 서버 인증서 검증: 브라우저가 서버의 인증서를 검증합니다.

  • 세션 키 생성: 브라우저와 서버는 세션 키를 생성하고, 이를 통해 암호화된 통신을 시작합니다.

5. HTTP 요청 전송

  • HTTP 요청 생성:

  • 브라우저는 서버에 HTTP 요청을 생성하여 전송합니다. 요청에는 HTTP 메서드(GET, POST 등), 경로, 헤더 정보가 포함됩니다.

6. 서버 처리 및 응답

  • 요청 처리:

  • 서버는 클라이언트로부터 받은 요청을 처리합니다. 서버는 웹 애플리케이션 로직을 실행하고 필요한 데이터를 조회하거나 수정합니다.

  • 응답 생성:

  • 서버는 요청에 대한 응답을 생성합니다. 응답에는 상태 코드(200, 404 등), 헤더 정보, 그리고 HTML 콘텐츠가 포함됩니다.

7. 브라우저 렌더링

  • HTML 파싱:

  • 브라우저는 수신한 HTML 문서를 파싱하여 DOM(Document Object Model) 트리를 생성합니다.

  • CSS 파싱 및 적용:

  • 브라우저는 CSS 파일을 파싱하여 스타일 규칙을 DOM 트리에 적용합니다. 이 과정을 통해 렌더 트리(Render Tree)를 생성합니다.

  • JavaScript 실행:

  • JavaScript 파일을 다운로드하고 실행하여 DOM을 동적으로 수정하거나 추가적인 데이터를 가져옵니다.

  • 레이아웃 계산:

  • 브라우저는 DOM과 CSSOM(CSS Object Model)을 기반으로 레이아웃을 계산하여 각 요소의 위치와 크기를 결정합니다.

  • 페인팅 및 컴포지팅:

  • 브라우저는 화면에 요소들을 그려 최종적으로 사용자가 보는 웹 페이지를 구성합니다.

8. 추가 요청 처리

  • 추가 리소스 요청:

  • 브라우저는 HTML 파싱 중에 필요한 추가 리소스(예: 이미지, CSS, JavaScript)를 비동기적으로 요청합니다.

  • 각 리소스는 별도의 HTTP 요청을 통해 가져오며, 이 요청들은 병렬로 처리됩니다.

  • 캐싱 및 최적화:

  • 브라우저는 리소스를 캐싱하여 동일한 리소스를 반복해서 다운로드하지 않도록 최적화합니다. 이는 페이지 로드 속도를 개선합니다.

13.REST 장단점을 설명해보세요.

REST의 장점

1. 단순성과 사용 용이성

  • HTTP 프로토콜 기반:

  • REST는 HTTP 프로토콜을 기반으로 하여 동작하므로, 별도의 프로토콜을 배우거나 설정할 필요가 없습니다.

  • HTTP의 표준 메서드(GET, POST, PUT, DELETE 등)를 사용하여 직관적으로 API를 설계하고 사용하기 쉽습니다.

  • 리소스 지향 아키텍처:

  • REST는 리소스를 URL로 표현하며, 각 리소스는 고유한 URI로 식별됩니다. 이는 API 설계를 간결하고 명확하게 합니다.

  • 표준화된 HTTP 상태 코드 사용:

  • REST API는 HTTP 상태 코드를 사용하여 클라이언트에게 응답 상태를 명확하게 전달합니다. 예를 들어, 200 OK, 404 Not Found, 500 Internal Server Error 등이 있습니다.

2. 확장성과 유연성

  • 클라이언트-서버 분리:

  • REST는 클라이언트와 서버 간의 명확한 분리를 제공합니다. 이는 각 구성 요소가 독립적으로 개발되고 확장될 수 있도록 합니다.

  • 스케일링 용이:

  • REST API는 여러 서버에 걸쳐 분산될 수 있으며, 이를 통해 높은 트래픽을 처리할 수 있는 확장성을 제공합니다.

  • 캐시 가능:

  • HTTP의 캐싱 메커니즘을 활용하여 REST 응답을 캐시할 수 있으므로, 클라이언트 측에서 네트워크 요청을 줄이고 성능을 향상시킬 수 있습니다.

3. 상태 비저장성 (Statelessness)

  • 스테이트리스 아키텍처:

  • REST는 상태 비저장성을 지향하며, 각 요청은 독립적이고 이전 요청의 상태에 의존하지 않습니다. 이는 서버 측의 상태 관리 부담을 줄이고, 확장성을 높입니다.

  • 간편한 확장 및 유지보수:

  • 서버는 클라이언트의 상태를 유지할 필요가 없으므로, 서버를 확장하거나 유지보수하는 데 유리합니다.

4. 다양한 데이터 형식 지원

  • 표현 형식의 다양성:

  • REST는 JSON, XML, HTML 등 다양한 데이터 형식을 지원합니다. 이는 클라이언트와 서버 간의 데이터 전송에 있어 유연성을 제공합니다.

  • JSON은 경량 데이터 형식으로, REST API에서 가장 널리 사용됩니다.

5. 광범위한 채택과 커뮤니티 지원

  • 표준화와 호환성:

  • REST는 많은 기업과 개발자 커뮤니티에서 채택되어 사용되고 있으며, 이를 통해 풍부한 라이브러리와 도구들이 제공됩니다.

REST의 단점

1. 복잡한 트랜잭션 처리

  • 트랜잭션 관리의 어려움:

  • REST는 상태 비저장성을 지향하기 때문에, 복잡한 트랜잭션을 관리하는 데 어려움이 있을 수 있습니다. 특히 여러 리소스에 걸친 트랜잭션 처리에는 적합하지 않을 수 있습니다.

  • 분산 트랜잭션의 비효율성:

  • 여러 서버 간에 걸친 트랜잭션을 처리할 때 일관성을 유지하기 어려울 수 있으며, 분산 트랜잭션 관리가 비효율적일 수 있습니다.

2. 초기 설정과 표준 부족

  • 표준의 부재:

  • REST는 아키텍처 스타일로 정의되어 있기 때문에 명확한 표준이 없습니다. 이는 개발자가 각자 다른 방식으로 구현할 가능성을 높이며, API 설계에 있어 일관성이 부족할 수 있습니다.

  • 표준화된 메타데이터 부족:

  • REST API에 대한 자동 문서화나 클라이언트 코드 생성과 같은 기능을 지원하기 위해 별도의 도구나 설정이 필요할 수 있습니다.

3. 오버헤드

  • 헤더 및 페이로드 오버헤드:

  • REST는 HTTP 프로토콜을 사용하므로, 각 요청 및 응답에 헤더 정보가 포함되어 오버헤드가 발생할 수 있습니다. 이는 특히 작은 데이터를 빈번하게 전송할 때 비효율적일 수 있습니다.

  • 대규모 데이터 전송의 비효율성:

  • REST는 큰 페이로드 전송에 최적화되어 있지 않아, 대규모 데이터 전송 시 비효율적일 수 있습니다.

4. 실시간 통신의 제한

  • 실시간 데이터 전송의 한계:

  • REST는 주로 요청-응답 기반 통신 모델을 따르기 때문에, 실시간 데이터 전송에는 적합하지 않습니다. 실시간 통신이 필요한 경우에는 WebSocket 같은 대안이 필요할 수 있습니다.

5. 보안 처리의 어려움

  • 표준 보안 메커니즘의 부족:

  • REST 자체에는 보안 메커니즘이 포함되어 있지 않으며, 인증 및 인가와 같은 보안 기능은 별도로 구현해야 합니다.

  • OAuth, JWT(JSON Web Tokens)와 같은 기술을 통해 보안을 강화할 수 있습니다.

  1. GET에 바디를 넣어서 보내면 나타날 결과를 설명해보세요.

HTTP GET 요청은 주로 리소스를 검색하거나 가져오기 위한 목적으로 사용되는 HTTP 메서드입니다. GET 요청은 URI에 의해 지정된 리소스를 서버에 요청하며, 서버는 해당 리소스를 반환합니다.

일반적인 HTTP GET 요청의 특징은 다음과 같습니다:

  • 캐싱: GET 요청은 서버가 동일한 요청에 대해 응답을 캐시할 수 있도록 설계되었습니다.

  • 멱등성: 동일한 GET 요청을 여러 번 보내더라도 서버 상태에는 영향을 주지 않습니다.

  • 무상태성: GET 요청은 서버 상태를 변경하지 않으며, 주로 리소스의 상태를 가져오는 데 사용됩니다.

  • 데이터 전송: GET 요청의 데이터는 URL 쿼리 매개변수를 통해 전송됩니다.

GET 요청에서 본문(Body)을 포함하는 경우

HTTP GET 요청에서 본문(Body)을 포함하는 것은 HTTP 표준에서 명시적으로 금지되어 있지는 않지만, 일반적인 관행과는 거리가 멉니다. 대부분의 HTTP 클라이언트 및 서버 구현에서는 GET 요청에 본문을 보내지 않으며, 본문을 처리하지 않습니다.

결과 및 영향

  1. 표준 준수 문제:

  • HTTP/1.1 표준(RFC 7231)에서는 GET 요청 본문에 대해 명시적으로 정의하지 않고 있으며, 본문이 있을 수 있다는 가능성을 열어두고 있습니다.

  • 그러나, GET 요청의 본문은 의미가 없다고 간주하며, 본문을 포함하는 것은 표준 관행에 어긋납니다.

  1. 서버의 처리:

  • 대부분의 서버 구현은 GET 요청의 본문을 무시합니다. 즉, 서버는 GET 요청의 본문에 있는 데이터를 읽거나 처리하지 않습니다.

  • 일부 서버는 본문이 포함된 GET 요청을 비표준으로 처리하거나 오류로 간주할 수 있습니다.

  1. 클라이언트와 서버 간의 비호환성:

  • 일부 HTTP 클라이언트 라이브러리나 프레임워크는 GET 요청에 본문을 포함하는 것을 허용하지 않으며, 본문을 포함하려고 시도할 경우 오류를 발생시킬 수 있습니다.

  • 예를 들어, curl과 같은 일부 클라이언트는 본문이 있는 GET 요청을 보낼 수 없도록 제한할 수 있습니다.

  1. 비정상적인 동작:

  • 특정 서버나 API가 비표준 동작을 구현하여 GET 요청의 본문을 읽고 처리할 수 있지만, 이는 일반적이지 않으며 다른 클라이언트나 서버와의 호환성을 저해할 수 있습니다.

  • 비표준 동작에 의존하는 코드는 유지보수 및 이식성이 떨어질 수 있습니다.

권장 사항

  • 쿼리 매개변수 사용: GET 요청에 데이터를 포함해야 하는 경우, URL 쿼리 매개변수(query parameters)를 사용하여 데이터를 전달하는 것이 표준적이며 안전한 방법입니다.

  • 예: GET /api/resource?id=123&name=example

  • POST 요청 사용: 서버에 데이터를 전송하고 처리해야 하는 경우, POST, PUT 또는 PATCH 요청을 사용하는 것이 적합합니다. 이들 메서드는 본문을 포함하는 것이 일반적이며, 서버가 데이터를 처리하도록 설계되었습니다.

  • API 문서 참조: 특정 API를 사용할 때 GET 요청에 본문을 포함할 수 있는지 여부는 해당 API의 문서를 참조하는 것이 좋습니다. 비표준 구현이 있을 수 있으므로, API 제공자가 이를 명시적으로 지원하는지 확인해야 합니다.

  1. POST와 PUT의 차이점을 설명해보세요.

POST (HTTP POST)

1. 주 목적 및 사용 사례

  • 리소스 생성(Create):

  • POST는 서버에 새로운 리소스를 생성하기 위해 주로 사용됩니다. 클라이언트가 서버로 데이터를 전송하면, 서버는 이를 기반으로 새로운 리소스를 생성합니다.

  • 예시: 사용자 등록, 블로그 게시글 작성, 새로운 데이터 엔트리 생성 등.

  • 서버 처리 요청:

  • POST는 리소스를 생성하는 것 외에도 서버에 특정 작업을 요청할 때 사용됩니다. 예를 들어, 파일 업로드, 트랜잭션 처리 등의 작업에 적합합니다.

2. 비멱등성(Non-idempotent)

  • 비멱등성:

  • POST 요청은 비멱등성을 가지며, 동일한 요청을 여러 번 전송하면 서버의 상태가 달라질 수 있습니다.

  • 예를 들어, 동일한 POST 요청을 두 번 보내면 두 개의 새로운 리소스가 생성될 수 있습니다.

3. 리소스 위치 및 URI

  • 서버 결정:

  • POST 요청에서는 서버가 생성된 리소스의 URI를 결정합니다. 클라이언트는 리소스의 위치를 사전에 알지 못하며, 서버가 URI를 생성하여 클라이언트에게 반환합니다.

PUT (HTTP PUT)

1. 주 목적 및 사용 사례

  • 리소스 업데이트(Update):

  • PUT은 주로 기존 리소스를 업데이트하는 데 사용됩니다. 요청 본문은 리소스의 전체 표현을 포함하며, 서버는 이를 기반으로 리소스를 덮어씁니다.

  • 예시: 사용자 프로필 업데이트, 기존 데이터 수정 등.

  • 리소스 생성(Create):

  • PUT은 지정된 URI에 리소스가 없을 경우 새로운 리소스를 생성할 수도 있습니다. 이는 클라이언트가 리소스의 위치를 알고 있는 경우에 해당합니다.

2. 멱등성(Idempotent)

  • 멱등성:

  • PUT 요청은 멱등성을 가지며, 동일한 요청을 여러 번 전송하더라도 서버의 상태가 달라지지 않습니다.

  • 동일한 PUT 요청을 여러 번 보내면 같은 결과를 얻으며, 서버 상태는 요청이 처음 도착했을 때와 동일하게 유지됩니다.

3. 리소스 위치 및 URI

  • 클라이언트 결정:

  • PUT 요청에서는 클라이언트가 리소스의 URI를 명시적으로 지정합니다. 클라이언트는 리소스가 위치할 URI를 알고 있어야 하며, 서버는 해당 위치에 리소스를 저장합니다.

OSI 7 계층과 TCP / IP 4 계층의 차이점은 무엇인가요?

OSI 7 계층 모델

OSI(Open Systems Interconnection) 모델은 ISO(International Organization for Standardization)에서 개발한 네트워크 참조 모델로, 네트워크 통신을 7개의 계층으로 나누어 설명합니다. 각 계층은 특정한 기능을 수행하며, 서로 독립적입니다.

OSI 7 계층 구성

  1. 물리 계층 (Physical Layer)

  • 역할: 물리적인 연결을 통해 데이터 전송을 담당합니다. 신호의 전기적, 기계적, 절차적 특성을 정의합니다.

  • 예: 케이블, 허브, 리피터 등

  1. 데이터 링크 계층 (Data Link Layer)

  • 역할: 인접한 네트워크 장치 간의 데이터 전송을 담당하며, 오류 검출 및 수정, 흐름 제어 등을 제공합니다.

  • 예: 스위치, 브리지, 이더넷

  1. 네트워크 계층 (Network Layer)

  • 역할: 패킷의 경로를 결정하고, 네트워크 간의 데이터 전송을 관리합니다.

  • 예: 라우터, IP(Internet Protocol)

  1. 전송 계층 (Transport Layer)

  • 역할: 종단 간(end-to-end) 데이터 전송을 관리하며, 데이터의 신뢰성 및 흐름 제어를 제공합니다.

  • 예: TCP(Transmission Control Protocol), UDP(User Datagram Protocol)

  1. 세션 계층 (Session Layer)

  • 역할: 애플리케이션 간의 세션을 설정, 관리 및 종료합니다. 세션의 동기화 및 체크포인팅을 제공합니다.

  • 예: NetBIOS, RPC(Remote Procedure Call)

  1. 표현 계층 (Presentation Layer)

  • 역할: 데이터의 표현 형식을 변환하고, 암호화 및 압축 등의 기능을 제공합니다.

  • 예: JPEG, GIF, TLS(Transport Layer Security)

  1. 응용 계층 (Application Layer)

  • 역할: 네트워크 서비스를 애플리케이션에 제공하며, 사용자 인터페이스와 직접 상호작용합니다.

  • 예: HTTP, FTP, SMTP

TCP/IP 4 계층 모델

TCP/IP 모델은 ARPANET의 초기 연구 결과를 바탕으로 개발된 네트워크 모델로, 인터넷의 핵심 프로토콜인 TCP와 IP를 중심으로 네트워크 통신을 설명합니다. OSI 모델보다 실용적이며, 인터넷에서 실제로 사용됩니다.

TCP/IP 4 계층 구성

  1. 네트워크 인터페이스 계층 (Network Interface Layer)

  • 역할: 물리적 네트워크 매체를 통해 데이터 전송을 담당합니다. OSI 모델의 물리 계층과 데이터 링크 계층에 해당합니다.

  • 예: 이더넷, Wi-Fi, ARP(Address Resolution Protocol)

  1. 인터넷 계층 (Internet Layer)

  • 역할: 패킷의 주소 지정 및 라우팅을 담당합니다. OSI 모델의 네트워크 계층에 해당합니다.

  • 예: IP, ICMP(Internet Control Message Protocol), IGMP(Internet Group Management Protocol)

  1. 전송 계층 (Transport Layer)

  • 역할: 종단 간 데이터 전송을 관리합니다. OSI 모델의 전송 계층에 해당합니다.

  • 예: TCP, UDP

  1. 응용 계층 (Application Layer)

  • 역할: 네트워크 서비스를 애플리케이션에 제공합니다. OSI 모델의 세션 계층, 표현 계층, 응용 계층을 포함합니다.

  • 예: HTTP, FTP, SMTP, DNS

상세 차이점 설명

  1. 계층의 수와 통합:

  • OSI 모델은 7개의 계층으로 나누어 각 계층이 독립적이고 명확하게 분리되어 있습니다. 이는 네트워크 기능을 세분화하여 관리할 수 있도록 도와줍니다.

  • TCP/IP 모델은 4개의 계층으로, 세션, 표현, 응용 계층이 응용 계층으로 통합되어 있습니다. 이는 실용성과 단순성을 중시하며, 인터넷 프로토콜 설계에 직접 사용됩니다.

  1. 프로토콜 의존성:

  • OSI 모델은 특정 프로토콜에 의존하지 않으며, 이론적이며 개념적인 모델로 모든 네트워크 프로토콜에 적용될 수 있습니다.

  • TCP/IP 모델은 TCP와 IP 프로토콜을 중심으로 설계되어 인터넷에서 실질적으로 사용되는 프로토콜에 최적화되어 있습니다.

  1. 실제 사용 및 적용:

  • OSI 모델은 네트워크 교육 및 이론적 연구에 주로 사용되며, 실제 네트워크 프로토콜 구현에서는 많이 사용되지 않습니다.

  • TCP/IP 모델은 인터넷 및 네트워크 통신에서 널리 사용되며, 대부분의 네트워크 프로토콜 및 응용 프로그램이 이 모델을 기반으로 합니다.

  1. 표준화 기관:

  • OSI 모델은 ISO(International Organization for Standardization)에서 개발한 국제 표준입니다.

  • TCP/IP 모델은 IETF(Internet Engineering Task Force)에서 개발한 인터넷 표준으로, RFC(Request for Comments) 문서를 통해 제안됩니다.

  1. 프로토콜의 구현 및 실용성:

  • OSI 모델은 개념적이고 구조적인 설계에 중점을 두며, 각 계층의 역할과 기능을 명확히 구분합니다.

  • TCP/IP 모델은 실용성과 효율성에 중점을 두며, 인터넷의 성장과 발전에 중요한 역할을 했습니다.

← 글 목록으로