미새문지

크래프톤 정글 week06, day48 - Datagram Socket vs Stream Socket, HTTP, 클라이언트-서버 트랜잭션, 잔디 심기 본문

크래프톤 정글/TIL

크래프톤 정글 week06, day48 - Datagram Socket vs Stream Socket, HTTP, 클라이언트-서버 트랜잭션, 잔디 심기

문미새 2024. 2. 25. 01:15
728x90

Datagram Socket vs Stream Socket

소켓

  • 소켓은 OS를 통해 네트워크 통신을 하는 표준 방법이다. 서버와 클라이언트가 데이터를 주고 받을 때 사용하는 함수이며, 데이터는 5계층인 세션 계층에서 전송된다.
  • 그리고 4계층의 구조를 결정하는 여러 종류의 소켓 타입이 있는데, 가장 보편적인 타입이 Stream SocketDatagram Socket이다.

 

Stream Socket

  • Stream Socket은 신뢰성 있는 양방향 통신을 제공한다.
    • 즉, 한쪽에서 다른 쪽의 연결을 초기화하고 연결이 생성된 후에는 어느 쪽에서든 다른 쪽으로 통신할 수 있다.
    • 또한 보낸 내용이 실제로 도착했는지도 즉각적으로 확인이 가능하다.
  • Stream Socket은 패킷을 오류없이 순서대로 도착하도록 설계된 TCP 표준 통신 프로토콜을 사용한다.
  • Stream Socket의 사용 예시
    • 웹 브라우징
      • 웹 브라우징은 HTTP 또는 HTTPS 프로토콜을 사용하며 TCP에 기반을 두고 있다.
      • TCP와 Stream Socket은 웹 브라우저와 서버 간의 통신에서 신뢰성 있는 데이터 전송을 보장한다.
    • 이메일 전송
      • 이메일 전송 프로토콜인 SMTP(Simple Main Transfer Protocol)도 TCP를 사용한다.
      • 이메일 클라이언트와 서버 간의 통신에서 TCP와 스트림 소켓은 메세지가 올바르게 전송되도록 한다.
    • 파일 전송
      • FTP(File Transfer Protocol)SFTP(Secure File Transfer Protocol) 같은 파일 전송 프로토콜은 TCP를 사용하여 파일을 안전하게 전송한다.
    • 온라인 게임
      • 실시간 온라인 게임은 플레이어 간의 실시간 통신을 위해 TCP를 사용할 수 있다.
      • 신뢰성 있는 데이터 전송이 중요한 게임에서는 TCP와 Stream Socket이 필요하다.

 

Datagram Socket

  • Datagram Socket의 연결은 단방향이고 신뢰할 수도 없고, 수신 측에서 데이터를 순서대로 받는다고 보장할 수도 없기 때문에 Datagram은 UDP(User Datagram Protocol)이라는 표준 프로토콜을 사용한다.
  • 특징
    • 비연결형
      • Datagram Socket은 연결을 설정하거나 유지하지 않아 연결 설정과 해제에 따른 시간이나 리소스를 절약할 수 있다.
    • 비신뢰성
      • Datagram Socket은 패킷의 전달이나 순서를 보장하지 않기 때문에, 패킷이 손실되거나 순서가 바뀌면 어플리케이션에서 이를 처리해야 한다.
  • Datagram Socket의 사용 예시
    • 온라인 멀티 게임
      • 실시간성이 중요한 온라인 멀티 게임에서는 Datagram Socket과 UDP를 사용한다.
    • 스트리밍 미디어
      • 라이브 방송이나 오디오 스트리밍에서는 실시간 데이터 전송이 중요하기 때문에 신속하게 전송해주는 Datagram Socket과 UDP를 사용한다.
      • 일부 패킷 손실은 버퍼링 또는 일시적인 품질 저하로 나타날 수 있다.
    • DNS(Domain Name System)
      • DNS 쿼리는 대개 UDP를 사용하여 Datagram Socket과 함께 작동한다.
      • DNS 서버에 질의하고 응답을 받는데 필요한 데이터는 작기 때문에 빠르게 처리하는 것이 중요하다.

HTTP(HyperText Transfer Protocol)

  • 텍스트 기반의 통신 규약으로 인터넷에서 데이터를 주고 받을 수 있는 프로토콜이다.
  • 클라이언트가 브라우저를 통해 어떤 서비스를 요청하면 서버에서는 해당 요청사항에 맞는 결과를 찾아 사용자에게 응답하는 형태로 동작한다.

  • 하지만 HTML 문서 외에도 JSON 데이터 및 XML과 같은 형태의 정보로도 HTTP 통신을 할 수 있다.

 

HTTP 특징

  • HTTP 메세지는 HTTP 서버와 HTTP 클라이언트에 의해 해석된다.
  • TCP/IP를 이용하는 응용 프로토콜이다.
  • HTTP는 연결 상태를 유지하지 않는 비연결성 프로토콜이다.
  • HTTP는 연결을 유지하지 않는 프로토콜이기 때문에 요청/응답 방식으로 동작한다.

 

 요청(Request)

  • 클라이언트가 서버에게 정보를 달라고 연락 보내는 것을 요청이라고 하며, 메세지를 보낼 때 요청에 대한 정보를 담아 서버로 보낸다.
  • 요청할 때 보내는 메세지는 세 부분으로 이루어져 있다.
    • HTTP 프로토콜의 요청 라인
      • 요청 방식(GET, POST, PUT, DELETE)
      • URL
    • Header
      • 요청에 대한 부가적인 정보(예 : URL, 사용자 인증 정보)
    • Body
      • 요청과 함께 전달되는 데이터를 포함한다.
      • 전달되는 데이터가 없을 경우 Body가 없을 수 있다.
  • 요청 메소드
    • GET : 자료를 요청할 때 사용
    • POST : 자료의 생성을 요청할 때 사용
    • PUT : 자료의 수정을 요청할 때 사용
    • DELETE : 자료의 삭제를 요청할 때 사용

 

응답(Response)

  • 서버가 클라이언트에서 요청한 정보를 보내주는 것을 응답이라고 하며, 요청한 정보를 메세지에 담아 클라이언트로 보낸다.
  • 응답할 때 보내는 메세지는 세 부분으로 이루어져 있는데
    • HTTP 프로토콜의 상태 라인
      • 응답 상태 코드(예 : 200)
      • 메세지
    • Header
      • 응답에 대한 부가적인 정보(콘텐츠 유형, 캐싱 정보)
    • Body
      • 서버가 전송하는 데이터(예 : HTML 페이지, JSON 데이터)

 

HTTP 헤더

  • 클라이언트와 서버가 요청 또는 응답으로 부가적인 정보를 전송할 수 있도록 한다.
  • 요청 헤더
    • Host : 요청 대상 서버의 도메인 이름 또는 IP 주소
    • Connection : 연결 유지 여부를 나타낸다.(예 : close())
    • Authorization : 사용자 인증 정보
    • Content-Type : 요청 데이터의 유형
    • Content-Length : 요청 데이터의 길이
  • 응답 헤더
    • Content-Type : 응답 데이터의 유형
    • Content-Length : 응답 데이터의 길이
    • Connection : 연결 유지 여부를 나타냄(예 : close())
    • Cache-Control : 캐싱 관련 지침
    • Location : 리다이렉션 URL(302 Found 경우)

 

메소드(Method)

  • 클라이언트와 서버 사이에 이루어지는 요청과 응답 데이터를 수행해야 할 동작을 지정해 요청을 보내는 방법이다.
  • 주요 메소드
    • GET : 리소스 조회
    • POST : 요청 데이터 처리, 주로 등록에 사용된다.
    • PUT : 리소스를 대체(덮어쓰기), 해당 리소스가 없으면 생성
    • PATCH : 리소스 부분 변경(PUT이 전체 변경, PATCH는 일부 변경)
    • DELETE : 리소스 삭제
  • 기타 메소드
    • HEAD : GET과 동일하지만 메세지 부분(body 부분)을 제외하고, 상태 줄과 헤더만 반환
    • OPTIONS : 대상 리소스에 대한 통신 가능 옵션(메소드)을 설명(주로 CORS에서 사용)
    • CONNECT : 대상 자원으로 식별되는 서버에 대한 터널을 설정
    • TRACE : 대상 리소스에 대한 경로를 따라 메세지 루프백 테스트를 수행
      • 루프백 : 다른 시스템에 연결하지 않고도 통신 링크를 테스트할 수 있게 하는 z/OS 플랫폼 기술

 

상태 코드

  • HTTP 응답의 결과를 나타내는 3자리 숫자 코드이며, 첫 번째 숫자는 응답의 종류를 나타낸다.
  • 종류
    • 200(OK) : 요청이 성공적으로 처리됐다.
    • 400(Bad Request) : 요청 문법에 오류가 있다.
    • 401(Unauthorized) : 사용자 인증이 필요하다.
    • 403(Forbidden) : 사용자에게 리소스에 대한 접근 권한이 없다.
    • 404(Not Found) : 요청된 리소스가 존재하지 않는다.
    • 405(Method Not Allowed) : 요청된 메소드가 허용되지 않는다.
    • 409(Conflict) : 요청과 충돌하는 리소스가 존재한다.
    • 410(Gone) : 요청된 리소스가 더 이상 존재하지 않는다.
    • 422(Unprocessable Entitiy) : 요청 엔티티가 처리될 수 없다.
    • 500(Internal Server Error) : 서버에 오류가 발생했다.
    • 501(Not Implemented) : 서버가 요청된 메소드를 지원하지 않는다.
    • 502(Bad Gateway) : 서버가 상위 서버로부터 잘못된 응답을 받았다.
    • 503(Service Unavailable) : 서버가 현재 사용할 수 없다.
    • 504(Gateway Timeout) : 서버가 상위 서버로부터 응답을 제때 받지 못했다.

 

HEAD 메소드

  • HTTP 요청 메소드 중 하나이며, 특정 리소스의 헤더 정보만 요청할 때 사용된다.
  • 특징
    • 헤더 정보를 확인한다.
      • 요청된 리소스의 존재 여부, 크기, 콘텐츠 유형, 캐싱 정보 등을 확인할 수 있다.
    • 리소스 바디를 전송하지 않는다.
      • GET 메소드와 달리 리소스의 실제 데이터는 전송하지 않는다.
    • 데이터 전송량 감소
      • 리소스 바디를 전송하지 않기 때문에 데이터 전송량을 줄일 수 있다.
  • HEAD 메소드와 GET 메소드 비교
기능 HEAD GET
리소스 바디 전송하지 않는다 전송한다
사용 목적 헤더 정보 확인, 링크 검사, 리소스 크기 확인 리소스 데이터 가져오기
데이터 전송량 적다 많다

 

  • 사용 예시
    • 링크 검사 : 링크가 유효한지 확인한다.
    • 리소스 크기 확인 : 다운로드 전에 리소스의 크기를 확인
    • 캐싱 정보 확인 : 리소스가 캐싱되어 있는지 확인
  • 활용
    • 웹 개발 : 리소스 정보 확인, 캐싱 관리
    • 웹 디버깅 : 리소스 문제 해결
    • 네트워크 모니터링 : 리소스 접근성 확인

클라이언트-서버 트랜잭션(Client-Server Transaction)

  • 네트워크 환경에서 서비스 요청 및 응답 과정을 포함하는 엔드-투-엔드(end-to-end) 프로세스
  • 클라이언트가 서버에 서비스를 요청하면, 서버는 이 요청을 처리하고 결과를 클라이언트에게 다시 전달한다.
    • 이 과정에서 트랜잭션 처리가 이루어져, 요청에 대한 응답이 일관되고 정확하게 이루어지도록 보장해야 한다.
  • 단계
    1. 요청(Request) : 클라이언트가 서비스를 필요로 할 때, 서버에 요청을 보낸다.
    2. 처리(Process) : 서버는 클라이언트의 요청을 받아 이에 대한 필요한 작업을 수행한다.
    3. 응답(Response) : 서버는 처리한 결과를 응답으로 클라이언트에 전송한다.
    4. 처리 결과 사용(Usage of Response) : 클라이언트는 서버로부터 받은 응답을 사용자에게 전달하거나 내부적으로 처리한다.
  • 예시)
    • 웹 서버에 페이지를 요청하는 HTTP 트랜잭션을 살펴보면, 클라이언트는 웹 브라우저가 되고 서버는 웹 페이지를 호스팅하는 웹 서버이다.
    • 클라이언트는 HTTP GET 요청을 보내고, 서버는 해당 요청에 맞는 HTML 페이지 또는 오류 메세지로 응답하는데, 이 과정을 트랜잭션이라고 부른다.

오늘의 잔디심기

백준
11387
JavaScript
실버3
님 무기가 좀 나쁘시네여
const fs = require("fs");
const filePath = process.platform === "linux" ? "/dev/stdin" : "./input.txt";
let input = fs.readFileSync(filePath).toString().split("\n");

const power = (h, w) => {
    return (h[0]+w[0]) * (100+h[1]+w[1]) * (100 * (100-Math.min(h[2]+w[2], 100)) + Math.min(h[2]+w[2], 100) * (h[3]+w[3])) * (100+h[4]+w[4]);
}

const Bitic = () => {
    const h1 = input[0].split(' ').map(Number);
    const h2 = input[1].split(' ').map(Number);
    const w1 = input[2].split(' ').map(Number);
    const w2 = input[3].split(' ').map(Number);
    
    for(let i =0; i < 5; i++) {
        h1[i] -= w1[i];
        h2[i] -= w2[i];
    }
    
    const diff1 = power(h1, w2) - power(h1, w1);
    const diff2 = power(h2, w1) - power(h2, w2);
    
    console.log(diff1 > 0 ? '+' : diff1 === 0 ? '0' : '-');
    console.log(diff2 > 0 ? '+' : diff2 === 0 ? '0' : '-');
}

Bitic();
728x90