[CS Study] Network Part.1

gom·2024년 3월 17일
CS공부일지네트워크
1

CS-Study

목록 보기
1/4
post-thumbnail

  • 1. 쿠키와 세션의 차이에 대해 설명해 주세요.

    • 답

      • 사용자의 정보가 저장되는 위치가 다름 (쿠키 : 서버 자원 사용 X / 세션 : 서버의 자원을 사용)

      • 보안은 세션이 더 좋음 (쿠키는 로컬에 저장되기 때문에 변질되거나 스니핑 당할 위험이 있음)

      • 요청 속도는 쿠키가 더 빠름 (세션은 서버의 처리가 필요하기 때문)

      • 쿠키는 만료시간이 있어도 파일로 저장되기 때문에 브라우저를 종료해도 정보가 남아있을 수 있지만 세션은 브라우저가 종료되면 만료 시간에 상관 없이 삭제됨

        쿠키

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

      • 사용자 인증이 유효한 시간을 명시할 수 있으며, 유효 시간이 정해지면 브라우저가 종료되어도 인증이 유지된다는 특징이 있음

      • 쿠키는 클라이언트의 상태 정보를 로컬에 저장했다가 참조

      • 클라이언트에 300개까지 쿠키저장 가능, 하나의 도메인당 20개의 값만 가질 수 있음, 하나의 쿠키값은 4KB까지 저장

      • Response Header에 Set-Cookie 속성을 사용하면 클라이언트에 쿠키를 만들 수 있음

      • 쿠키는 사용자가 따로 요청하지 않아도 브라우저가 Request시에 Request Header를 넣어서 자동으로 서버에 전송

        세션

      • 세션은 쿠키를 기반하고 있지만, 사용자 정보 파일을 브라우저에 저장하는 쿠키와 달리 세션은 서버 측에서 관리

      • 서버에서는 클라이언트를 구분하기 위해 세션 ID를 부여하며 웹 브라우저가 서버에 접속해서 브라우저를 종료할 때까지 인증상태를 유지

      • 물론 접속 시간에 제한을 두어 일정 시간 응답이 없다면 정보가 유지되지 않게 설정 가능

      • 사용자에 대한 정보를 서버에 두기 때문에 쿠키보다 보안에 좋지만, 사용자가 많아질수록 서버 메모리를 많이 차지하게 됨

        → 즉 동접자 수가 많은 웹 사이트인 경우 서버에 과부하를 주게 되므로 성능 저하의 요인이 됨

      • 클라이언트가 Request를 보내면, 해당 서버의 엔진이 클라이언트에게 유일한 ID를 부여하는 데 이것이 세션 ID

    1. 세션 방식의 로그인 과정에 대해 설명해 주세요.

      • 답

        사용자가 로그인할 때 서버에서 세션 ID를 생성하고 이를 쿠키를 통해 클라이언트에 전달 → 이후 사용자는 해당 사이트에 대한 모든 request에 세션 ID를 쿠키에 담아 전송 → 서버는 클라이언트가 보낸 세션ID와 세션 저장소에서의 세션ID를 비교해서 일치하면 인가 수행

    2. HTTP의 특성인 Stateless에 대해 설명해 주세요.

      • 답 Stateless란 무상태 즉, 클라이언트와 서버 관계에서 서버가 클라이언트의 상태를 보존하지 않음을 의미함 HTTP 레벨에서는 이전에 보냈던 request나 response를 기억하지 못하기 때문에 HTTP 요청은 직전의 요청과 관련이 없음 HTTP는 Stateless한 특성을 가져 각 통신의 상태가 저장되지 않기 때문에 웹사이트에서 인증을 관리하기 위한 방법이 필요함

    3. Stateless의 의미를 살펴보면, 세션은 적절하지 않은 인증 방법 아닌가요?

      • 답 HTTP의 Stateless 특성에는 상태를 유지하는 세션이 맞지 않는 것처럼 보일 수 있음 하지만 매번 인증을 하는 것 또한 사용자 입장에서 굉장히 불편함 또한 무상태를 지향하기 위해 매 요청마다 필요한 정보를 모두 담아 서버에게 요청 및 응답 받는 경우 통신에서 오는 부하와 비용이 더 클 가능성이 있음 ⇒ 무상태 특성이 있지만 손해를 최소화하기 위해 세션방식을 사용함

    4. 규모가 커져 서버가 여러 개가 된다면, 세션을 어떻게 관리할 수 있을까요?

      • 답

        여러 개의 서버가 세션을 공유하도록 한다.

        공유방법 1 Session Clustering

        • 각 서버의 세션 저장소를 하나로 묶어서 관리하는 방법

        • 모든 서버가 동일한 세션을 공유하여 특정 서버로만 트래픽이 몰리지 않음

        • 하나의 서버가 죽어도 세션 정보를 잃지 않음

        • 단점
          - 모든 서버의 세션 데이터를 동일하게 유지하기 위해 하나의 세션이 생기면 모든 서버의 세션 저장소를 업데이트해야 함 → 그만큼 많은 메모리가 필요하여 성능저하 발생
          - 새로운 서버를 만들 때마다 기존의 세션 데이터를 옮겨 클러스터링해야 하는 번거로움 존재

          공유방법 2 Session Server

        • 세션만 관리하는 별도의 서버를 하나 두는 방식

        • 모든 서버의 세션 저장소를 업데이트하거나 클러스터링 할 필요 없음

        • Redis같은 In-memory 데이터 저장소를 사용함으로써 빠르게 세션을 조회할 수 있음

  • 2. HTTP 응답코드에 대해 설명해 주세요.

    • 답

      HTTP 상태코드

      • 1xx - informational

        • 거의 사용 X

      • 2xx - successful

        • 성공적으로 처리 시 사용
        • 200 OK
        • 201 Created
        • 202 Accepted
        • 204 No Content

      • 3xx - redirection

        • 유저의 추가 조치 필요

        • 완전한 처리를 위해 추가 동작이 필요한 경우

        • 주로 서버의 주소 또는 요청한 URI의 웹 문서가 이동되었으니 그 주소로 다시 시도하라는 의미

        • 리다이렉션 종류

          • 영구 리다이렉션 - 301, 308
          • 일시 리다이렉션 - 302, 307, 303
          • 특수 리다이렉션

      • 4xx - client error

        • 클라이언트의 요청 메시지 내용이 잘못된 경우
        • 400 Bad request
        • 401 Unauthorized
        • 403 Forbidden
        • 404 Not Found

      • 5xx - server error

        • 서버 사정으로 메시지 처리에 문제가 발생한 경우
        • 서버에서 부하, DB처리 과정 오류, 서버에서 익셉션이 발생하는 경우
        • 500 Internal Server Error
        • 503 Service Unavailable

    • 401 (Unauthorized) 와 403 (Forbidden)은 의미적으로 어떤 차이가 있나요?

      • 답 401(Unauthorized)은 로그인이 되어있지 않은 상태에서 무언가를 요청하는 경우와 같이 클라이언트가 인증되지 않았거나, 유효한 인증 정보가 부족하여 요청이 거부되었음을 의미하는 상태값 403(Forbidden)은 로그인하여 인증되었지만 접근 권한이 없는 요청을 수행한 경우와 같이 인증된 클라이언트가 해당 요청에 대한 권한이 없다고 알려주는 것 401은 요청한 리소스에 대한 액세스 권한이 없는 경우이고 403은 요청한 리소스에 대한 액세스가 금지된 경우임 ⇒ 401은 인증 이 되지 않은 경우, 403은 인가 되지 않은 경우

    • 200 (ok) 와 201 (created) 의 차이에 대해 설명해 주세요.

      • 답 200(ok)은 서버가 요청을 성공적으로 처리하였을 때의 응답코드 201(created)은 요청이 처리되어서 새로운 리소스가 생성되었을때의 응답 코드, 응답 헤더 Location에 새로운 리소스의 절대 URI를 기록함 두 코드 모두 서버가 요청을 성공적으로 처리했음을 의미하지만 201은 성공한 요청이 POST/PUT을 통해 새로운 데이터를 쓰거나 추가하는 작업에 성공했다는 의미

    • 필요하다면 저희가 직접 응답코드를 정의해서 사용할 수 있을까요? 예를 들어 285번 처럼요.

      • 답

        필요한 경우 사용자가 직접 응답코드를 정의해서 사용할 수 있음

        다만, 표준 응답 코드와 충돌하지 않도록 주의해야 하며 사용자가 정의한 코드는 문서화되어 클라이언트와 공유되어야 함

  • 3. HTTP Method 에 대해 설명해 주세요.

    • 답

      HTTP 메서드

      • GET : 조회

      • POST : 요청 데이터 처리

      • PUT : 리소스 대체

      • PATCH : 부분 변경

      • DELETE : 삭제

        GET

      • 조회시 사용

      • 서버에 전달하고 싶은 데이터는 쿼리를 통해 전달

      • 메세지 바디를 사용하는 것은 권장 X

        POST

      • 요청 데이터 처리

      • 메시지 바디를 통해 서버로 요청 데이터를 전달

      • 서버는 요청 데이터 처리

      • 주로 신규 리소스 등록이나 프로세서 처리에 사용

      • 다른 메서드로 처리하기 애매한 경우에도 사용

        PUT

      • 리소스 대체 - 있으면 대체 없으면 생성

      • 클라이언트가 리소스를 식별!!
        - 클라이언트가 리소스 위치를 알고 URI 지정함 - POST와의 차이점

        PATCH

      • 부분 수정을 위해 사용

      • 사용 못하는 경우도 있음 - POST 사용하면 됨

        DELETE

      • 리소스 삭제시 사용

        OPTIONS

      • 리소스가 지원하고 있는 메소드를 취득합니다.

        CONNECT

      • 프록시 동작의 커널 접속을 변경합니다.

        TRACE

      • 대상 리소스에 대한 경로를 따라 메시지 루프백 테스트를 수행합니다.

    • HTTP Method의 멱등성에 대해 설명해 주세요.

      • 답

        동일한 요청을 몇 번을 호출하든 최종 결과가 똑같은 성질

        즉, 멱등한 메소드는 같은 요청을 여러 번 실행하더라도 서버의 상태가 변하지 않거나 동일한 상태로 유지됨

        외부 요인으로 리소스가 변경되는 것은 고려하지 않음

    • GET과 POST의 차이는 무엇인가요?

      • 답
        • GET은 주로 서버의 리소스를 조회 요청하는데 사용하며, POST는 클라이언트의 데이터를 서버측에서 처리 요청하는데 사용하는 메서드임
        • GET을 필요한 파라미터를 주로 쿼리스트링으로 전달하지만 POST는 body 에 담아 전달함

    • POST와 PUT, PATCH의 차이는 무엇인가요?

      • 답 POST는 주로 새로운 데이터를 생성할 때 사용하고, PUT은 기존의 데이터를 전부 수정할 때, PATCH는 기존의 데이터의 일부를 수정할 때 사용하는 방법임

    • HTTP 1.1 이후로, GET에도 Body에 데이터를 실을 수 있게 되었습니다.
      그럼에도 불구하고 왜 아직도 이런 방식을 지양하는 것일까요?
      - 답
      1. 캐싱 및 브라우저 호환성
      - GET요청은 캐싱이 잘 이루어지기 때문에, 반복된 요청에는 캐싱을 사용해서 응답할 수 있음

                  BUT!! body에 데이터를 담아 보내면 캐싱이 어려워지는 문제가 있을 수 있음
            
            → 캐싱이나 프록시 설계 일부는 GET의 body값을 참조하지 않는 경우가 있기 때문
            
        - 중간에 캐시 프록시 서버가 있는 경우, 쿼리 파라미터를 활용한 GET 요청 시 프록시 서버가 중간에 캐싱하여 다수의 클라이언트에 동일한 데이터를 제공할 수 있지만, 데이터를 body에 담아 보내는 경우 이러한 캐싱이 어려워질 수 있음
    2. **어떤 메소드를 사용해야 할지 명확한 분리**
        - HTTP의 설계 원칙에 따르면 GET은 정보를 요청하고 POST는 데이터를 제출하는 역할로 분리되어야 함
        - 본문을 포함한 GET 요청은 이러한 역할 분리를 어렵게 만들 수 있음
    3. **서버 및 프록시 제약**
        - 일부 서버 및 프록시 서버는 GET 요청에서 본문을 지원하지 않거나 처리하지 않을 수 있음

  • 4. HTTP에 대해 설명해 주세요.

    • 답 HyperText Transfer Protocol 텍스트 기반의 통신 규약으로 인터넷에서 데이터를 주고받을 수 있는 프로토콜 거의 모든 형태의 데이터를 전송 가능 서버간의 데이터 송신에서도 대부분 사용함
    • 공개키와 대칭키에 대해 설명해 주세요.
      • 답

        공개키

        • 암호화와 복호화에 사용하는 키가 서로 다름

        • 비대칭키 암호화라고도 함

        • 속도가 느린 단점이 있지만 기밀성/인증/부인방지 기능을 제공함

        • 키분배 필요가 없음

        • 방식

          • 암호 모드 : 송신자 공개키로 암호화 -> 송신자 사설키로 복호화소량의 메시지 암호화 목적, 주로 키 교환의 용도로 사용
          • 인증 모드 : 송신자 사설키로 암호화 -> 송신자 공개키로 복호화메시지를 인증(부인방지)하는 것이 목적

        • 대표적인 알고리즘
          - Diffie Hellman : 최초의 공개키 알고리즘, 위조에 취약
          - RSA : 대표적 공개키 알고리즘
          - DSA : 전자서명 알고리즘 표준
          - ECC : 짧은 키로 높은 암호 강도, 빠른 구현 가능 PDA, 스마트폰등에 사용

          대칭키

        • 암호화와 복호화에 사용하는 키가 동일함

        • 속도가 빨라 대용량 Data 암호화에 적합하다는 장점이 있음

        • 키를 교환해야하는 문제, 탈취 관리 걱정, 사용자 증가에 따른 키관리 어려움, 확장성이 떨어진다는 단점이 있음

        • 기밀성을 제공하나, 무결성/인증/부인방지 를 보장하지 않음

        • 대표적 알고리즘 : 공인인증서의 암호화방식으로 유명한 SEED, DES, 3DES, AES, ARIA, 최근 주목받고 있는 암호인 ChaCha20

    • 왜 HTTPS Handshake 과정에서는 인증서를 사용하는 것 일까요?
      • 답 HTTP 통신 중에 누군가 중간에서 정보를 탈취하면 유저의 정보가 그대로 노출됨 이러한 치명적인 보안적 허점을 해결하기 위해 인증서를 발급받고, 그 인증서를 기반으로 데이터를 인코딩하여 주고받음 → 누군가 탈취해도 알아볼 수 없음
    • SSL과 TLS의 차이는 무엇인가요?

      • 답

        1. 메시지 인증

          SSL과 TLS의 주요 차이점은 메시지 인증입니다.

          SSL은 메시지 인증 코드(MAC)를 사용하여 전송 중에 메시지가 변조되지 않도록 합니다.

          TLS는 보호를 위해 MAC을 사용하지 않고 대신 암호화와 같은 다른 수단을 사용하여 변조를 방지합니다.

        2. 기록 프로토콜

          레코드 프로토콜은 TLS와 SSL 모두에서 보안 통신 채널을 통해 데이터를 전송하는 방식이지만, 몇 가지 사소한 차이점이 있습니다.

          TLS에서는 패킷당 하나의 레코드만 가져올 수 있는 반면, SSL에서는 패킷당 여러 개의 레코드가 전송될 수 있습니다(거의 구현되지 않았지만).

          또한 압축 및 패딩 옵션과 같은 TLS의 레코드 프로토콜의 일부 기능은 SSL에 포함되어 있지 않습니다.

        3. 사이퍼 스위트

          TLS는 암호화 및 암호 해독에 사용되는 알고리즘인 다양한 암호 제품군을 지원합니다. 가장 잘 알려진 암호 집합은 타원 곡선을 기반으로 하는 임시 DHE(Diffie-Hellman) 키 교환으로, 완벽한 순방향 비밀성(PFS)을 제공하며 모든 키 길이에 사용할 수 있습니다. 다른 몇 가지 암호 제품군도 PFS를 지원하지만 널리 사용되지는 않습니다. SSL은 1024비트 RSA 키를 사용하는 PFS를 사용하는 하나의 암호 제품군만 지원합니다.

        4. 알림 메시지

          SSL 프로토콜은 경고 메시지를 사용하여 통신 중 특정 오류에 대해 클라이언트 또는 서버에 알립니다. TLS 프로토콜에는 이와 동등한 메커니즘이 없습니다.

          💡 간단히 말해, SSL은 더 이상 사용되지 않으며, TLS는 현재 모든 사람이 사용하는 암호화 표준으로 구식 SSL 프로토콜을 대체하는 새로운 용어입니다. 기술적으로 TLS가 더 정확하지만 SSL이 널리 사용됩니다.

          SSL

        • 컴퓨터 네트워크를 통해 통신 보안을 제공하는 암호화 프로토콜

        • 암호화를 사용하여 데이터의 무결성과 기밀성을 보호함

        • 현재는 사용 종료됨

          TLS

        • 인터넷을 통한 보안 통신을 위한 표준

        • 클라이언트/서버 애플리케이션이 도청 및 정보 변조를 방지하도록 설계된 방식

        • 네트워크를 통해 통신할 수 있도록 함

        • SSL의 업데이트 버전으로 TLS와 SSL을 혼용하여 부름

  • 5. 웹소켓과 소켓 통신의 차이에 대해 설명해 주세요.

    • 답

      차이점

      • 소켓은 인터넷 프로토콜에 기반하기 때문에 TCP, UDP가 속한 4계층에 위치하고, 웹 소켓은 HTTP에 기반하므로 7계층에 위치함

      • 소켓 통신은 바이트 스트림을 통한 데이터 전송이기 때문에 바이트로 이루어진 데이터를 다루지만, 웹 소켓은 어플리케이션 계층인 7계층에 기반하기 때문에 메시지 형식의 데이터를 다룸

        둘은 상반된 개념이 아니기 때문에 완전하게 차이점을 비교할 수 없음

        웹 소켓은 TCP 소켓과 구분되는 것이 아니라 TCP 소켓의 추상화된 형태이다.

        소켓 통신에 기반하여 웹 소켓은 웹 어플리케이션에 맞게 발전한 형태로 소켓 통신을 한다

        소켓(Socket)

      • 네트워크 상에서 수행되는 두 프로그램 간의 양방향 통신 링크의 한쪽 끝 단을 의미

      • 네트워크를 통해 데이터를 송수신하는 데 사용되는 소프트웨어 엔드포인트

      • OS 커널에 구현되어 있는 프로토콜 요소에 대한 추상화된 인터페이스

      • 1:1 통신의 경우 양측 다 소켓이 존재해야 통신 가능

        웹 소켓 (Web Socket)

      • 하나의 TCP 접속에 전이중 통신 채널을 제공하는 컴퓨터 통신 프로토콜

      • HTTP나 HTTPS 위에서 동작하도록 설계되었음 → 포트 80이나 443

      • HTTP 프로토콜과 구별되지만 호환됨

    • 소켓과 포트의 차이가 무엇인가요?

      • 답

        차이점

        • 소켓은 통신 경로를 제공하고 관리하는 역할을 하고, 포트는 통신 과정에서 데이터가 어떤 프로세스나 서비스에 도달해야 하는 지를 구분함

          소켓 (Socket)

        • 클라이언트-서버 모델에서 클라이언트와 서버 사이에 데이터를 전송할 수 있는 통신 경로를 제공해주는 일종의 톨게이트

          포트 (Port)

        • 네트워크에서 특정 소프트웨어에 데이터를 전달하기 위한 통신 채널을 식별하는 번호

        • 0~65535 범위를 가짐

        • 일반적으로 잘 알려진 포트 번호와 동적 포트 번호로 나뉨

          • HTTP : 80번 포트, HTTPS : 443번 포트

    • 여러 소켓이 있다고 할 때, 그 소켓의 포트 번호는 모두 다른가요?

      • 답
        • 모두 다를 수도 있고, 포트 번호가 같은 소켓이 있을 수도 있음
        • 포트 번호는 하나의 호스트 내에서 고유해야 하지만 소켓은 여러 개를 생성할 수 있음 → 같은 IP, 같은 포트수를 가지고 있더라도 여러 개의 소켓이 존재할 수 있음

    • 사용자의 요청이 무수히 많아지면, 소켓도 무수히 생성되나요?

      • 답

        • 사용자의 요청이 많아질수록 소켓의 수가 증가할 수 있음
        • 하지만, 소켓을 생성하고 관리하는 것이 시스템 자원을 많이 소모하는 작업으로 시스템 자원이 가능한 범위까지만 소켓이 생성됨

  • 6. HTTP/1.1과 HTTP/2의 차이점은 무엇인가요?

    • 답

      차이점

      1. HTTP Body가 이진 데이터임

        • 기존 HTTP는 바디가 문자열로 이루어져 있지만 HTTP/2부터는 binary framing layer라는 공간에 이진 데이터로 전송됨 ⇒ HTTP Request Method, 헤더 등은 여전히 문자열로 전송되지만 바디 부분이 변경되는 것이 가장 큰 변경점 중 하나임

      2. 멀티 플렉싱 지원

        • 1.1은 piplining 기술을 도입해도 여전히 HOL (Head-of-Line) Blocking 문제가 있음 ** HOL Blocking : 패킷은 순서대로 도착해야 하기 때문에 패킷이 도착할 때까지 이후의 패킷들은 전송되지 못함
        • 하지만 2.0이 되면서 스트림을 이용하여 해당 문제를 해결함
          • 스트림 장점
            • 여러 요청/응답을 병렬로 처리 (하나의 TCP에 여러 스트림 사용)
            • TCP 연결이 1개이기 때문에 3-way-handshake 오버헤드 없음
            • 네트워크 가용성 증가로 속도 상승 및 이미지 스트라이트 등을 사용하지 않아도 됨

      3. 스트림 우선순위 지정

        • 우선 순위가 더 높은 리소스를 먼저 응답할 수 있음
        • 전송 순서를 임의로 고정시킬 수 없으나, 중요한 데이터를 먼저 보낼 수 있도록 설정할 수 있음

      4. 헤더 압축
        - 1.0에서는 헤더가 문자열로 전송되어 성능 이슈를 일으켰지만 2.0에서는 HPACK압축을 이용하여 헤더를 압축해서 보냄

        HTTP/1.1 (표준 프로토콜)

      • HTTP 헤더 + 바디로 구성되어 있음

        • 헤더에는 URI, Request Method, 여러 헤더 정보가 포함되어 있음

      • 사람이 읽을 수 있는 문자열이 그대로 전송됨

      • TCP connection을 이용함

        • 3-way-handshake를 사용하게 되어있음

      • connection을 재사용 함

        • 통신에 사용된 connection을 즉시 끊지 않고, 대기하였다가 추가 요청이 있을 경우 재활용함

      • 파이프라이닝 추가
        - 요청에 대한 응답이 끝나기 전에 다음 데이터를 미리 요청함

        HTTP/2

      • 모든 통신을 단일 TCP 연결을 통해 이뤄질 수 있고, 스트림의 개수는 제한이 없음

      • 각 스트림은 고유 식별자와 우선수위 정보(선택사항)이 있음

      • 프레임은 통신의 최소 단위 → TCP가 데이터를 쪼개서 보낸 다음 헤더를 보고 재 조립 하는 것과 비슷함

    • HOL Blocking 에 대해 설명해 주세요.
      • 답 패킷은 순서대로 도착해야 하기 때문에 패킷이 도착할 때까지 이후의 패킷들은 전송되지 못하는 것
    • HTTP/3.0의 주요 특징에 대해 설명해 주세요.
      • 답 TCP 기반으로 사용되던 이전 HTTP와 다르게 HTTP/3.0부터는 UDP 기반의 QUIC (Quick UDP Internet Connection)프로토콜을 사용함 ** TCP 는 3-way-handshake, 끝날 때 4-way-handshake 등 오버헤드와 HOL Blocking 등의 문제를 가짐 ⇒ QUIC 은 TCP handshake 과정을 최적화하는 것에 집중하여 설계됨

  • 7. TCP와 UDP의 차이에 대해 설명해 주세요.

    • 답

      차이점

      TCP(Transmission Controle Protocol)

      • 인터넷상에서 데이터를 메세지의 형태로 보내기 위해 IP와 함께 사용하는 프로토콜

      • 연결 지향 방식으로 패킷 교환 방식을 사용

      • 3-way handshake 과정을 통해 연결을 설정하고 4-way handshake을 통해 해제함

      • 흐름 제어 및 혼잡 제어

        • 네트워크 상황과 클라이언트의 데이터 처리 능력을 고려하여 데이터 전송 속도를 조절
        • 네트워크의 혼잡 상태를 감지하고, 혼잡을 완화하기 위해 데이터 전송 속도를 조절

      • 높은 신뢰성을 보장

        • 데이터 손실이 발생했을 때 재전송을 요청하고, 도착한 데이터의 순서를 관리하여 데이터를 제공함

      • UDP 보다 속도가 느림

      • 전이중(Full-Duplex), 점대점(Point to Point) 방식

        UDP(User Datagram Protocol)

      • 데이터를 데이터그램 단위로 처리하는 프로토콜

      • 비연결 방식으로 데이터 그램 패킷 교환 방식을 사용함

      • 신뢰성이 떨어짐

        • 패킷의 도착을 보장하지 않으며, 순서대로 도착한다는 보장도 없음
        • 데이터 패킷이 손실되거나 순서가 바뀌어도 재전송을 요청하지 않음

      • 효율적으로 데이터를 전송함

        • 연결 설정과 상태 유지에 필요한 오버헤드가 없기 때문에 빠른 데이터 전송이 필요한 실시간 애플리케이션에서 많이 사용됨

      • 헤더 오버헤드가 적음

        • UDP 헤더는 8 바이트로, 전송해야 할 데이터 양이 적은 경우에 유리함

      • TCP 보다 속도가 빠름

    • Checksum이 무엇인가요?

      • 답
        • 데이터의 정확성을 검증하기 위해 사용되는 간단한 방법 중 하나
        • 파일, 메시지, 또는 패킷의 무결성을 확인하는데 사용됨

    • TCP와 UDP 중 어느 프로토콜이 Checksum을 수행할까요?

      • 답
        • TCP와 UDP 둘 다 Checksum을 수행함
        • 하지만 TCP에서는 필수적이고, UDP는 선택적임

    • 그렇다면, Checksum을 통해 오류를 정정할 수 있나요?

      • 답
        • Checksum으로 데이터 오류의 발생 여부만 확인할 수 있음
        • 오류가 어디서 어떻게 발생했는지는 알 수 없음

    • TCP가 신뢰성을 보장하는 방법에 대해 설명해 주세요.

      • 답
        1. ACK 필드를 이용하여 데이터를 수신하였는지 확인하는 요청/응답을 보냄
        2. 데이터의 순서를 관리
        3. 흐름제어
          • 수신자가 처리할 수 있는 데이터의 양을 슬라이딩 윈도우 기능을 통해 제어
        4. 혼잡제어
          • 네트워크 정체 신호를 모니터링하여 네트워크 과부하를 방지
        5. 오류감지
          • checksum을 사용하여 데이터의 오류 여부를 검사

    • TCP의 혼잡 제어 처리 방법에 대해 설명해 주세요.

      • 답
        1. 느린 시작(Slow Start)
          • 연결 시작 시 속도를 점진적으로 늘려, 네트워크 용량을 탐색
        2. 혼잡 회피(Congestion Avoidance)
          • 네트워크 혼잡을 감지하면, 전송 속도 증가를 늦춰 혼잡을 관리
        3. 혼잡 감지
          • 패킷 손실(예: 타임아웃, 중복 ACK)을 통해 네트워크 혼잡을 감지하고, 전송 속도를 조정
        4. 빠른 회복(Fast Recovery)
          • 혼잡 발생 시 윈도우 크기를 줄여 빠르게 회복하고, 전송을 재개

    • 왜 HTTP는 TCP를 사용하나요?

      • 답
        • HTTP는 서버-클라이언트 모델 기반으로 통신을 제공하므로 데이터의 무결성과 신뢰성이 중요함 ⇒ 신뢰성이 좋은 TCP 사용

    • 그렇다면, 왜 HTTP/3 에서는 UDP를 사용하나요? 위에서 언급한 UDP의 문제가 해결되었나요?

      • 답
        • 성능 향상과 연결의 효율성을 개선하기 위해 HTTP/3에서 UDP를 사용함
        • QUIC는 UDP의 기본적인 특성을 활용하면서도 TCP에서 제공하는 신뢰성, 순서 보장, 흐름 제어, 혼잡 제어와 같은 중요한 기능들을 자체적으로 구현함 ⇒ UDP의 문제점이 해결됨

    • 그런데, 브라우저는 어떤 서버가 TCP를 쓰는지 UDP를 쓰는지 어떻게 알 수 있나요?

      • 답
        1. HTTP 요청 메시지
          • 브라우저가 HTTP 요청 메시지를 서버에 전송할 떄 요청 메시지의 헤더에 프로토콜 정보를 포함함
        2. TCP/UDP 포트 번호
          • 브라우저는 서버의 포트 번호를 확인하여 해당 서버가 사용하는 프로토콜을 파악할 수 있음
          • HTTP 프로토콜 : TCP 포트 80번 사용 / HTTPS 프로토콜 : TCP 포트 443번 사용
        3. DNS 조회
          • 브라우저는 서버의 IP주소를 얻기 위해 DNS조회하는데 그 결과에 서버가 사용하는 프로토콜 정보가 포함될 수 있음
        4. TLS 연결
          • 브라우저는 HTTPS 프로토콜을 사용하여 서버와 통신할 때 TLS 연결을 설정하는데, TLS 연결 과정에서 서버는 자신이 사용하는 프로토콜 정보를 브라우저에 전달함

    • 본인이 새로운 통신 프로토콜을 TCP나 UDP를 사용해서 구현한다고 하면, 어떤 기준으로 프로토콜을 선택하시겠어요?

      • 답
        • 데이터 전송 시 신뢰성이 보장되어야 하는지, 데이터 전송량이 어느정도 되는지 그리고 데이터 전송 속도를 중요시하는지를 고려하여 새로운 통신 프로토콜을 구현할 것 같습니다.

  • 8. DHCP가 무엇인지 설명해 주세요.

    • 답

      DHCP (Dynamic Host Configuration Protocol)

      • 네트워크의 컴퓨터 및 기타 장치에 IP 주소를 할당하기 위한 표준화 된 프로토콜

      • 네트워크 관리자가 각 장치에 수동으로 IP 주소를 할당하는 번거로움 없이 장치들이 네트워크에 연결될 때 자동으로 필요한 네트워크 구성 정보를 받을 수 있음

        💡 네트워크 관리를 단순화하고 IP 주소를 효율적으로 관리할 수 있게 해줌

      • 구성 요소

        1. DHCP 서버
          • 네트워크 상의 중앙 장치로, IP 주소 및 기타 네트워크 구성 정보를 동적으로 관리하고 할당
        2. DHCP 클라이언트
          • 네트워크에 연결하는 장치(컴퓨터, 스마트폰, 태블릿 등)로, DHCP 서버로부터 IP 주소와 네트워크 구성 정보를 동적으로 받음
          • DHCP 클라이언트는 네트워크에 연결할 때 자동으로 DHCP 서버에 IP 주소를 요청하고, 할당된 IP 주소의 임대 기간이 만료되면 연장을 요청하거나 새로운 IP 주소를 요청할 수 있음
        3. DHCP 릴레이
          • DHCP 서버와 DHCP 클라이언트는 네트워크 상의 다른 세그먼트에 위치하여 있기 때문에 둘 사이의 중계하는 역할을 하는 장치

    • DHCP는 몇 계층 프로토콜인가요?

      • 답 Application 계층(7계층) 프로토콜임

    • DHCP는 어떻게 동작하나요?

      • 답

        1. DHCP Discover
          • 클라이언트는 IP 주소를 요청하기 위해 네트워크 상의 DHCP 서버를 찾아 DHCP Discover 메시지를 브로드캐스트
        2. DHCP Offer
          • DHCP 서버는 DHCP Offer 메시지를 통해 클라이언트에게 IP 주소를 제안
          • 메시지에는 클라이언트에 할당된 IP 주소와 주소의 임대 시간(Lease Time)이 포함됨
        3. DHCP Request
          • 클라이언트는 제안받은 IP 주소에 대해 DHCP Request 메시지를 통해 수락 의사를 전달
          • 이 단계에서 클라이언트는 여러 DHCP 서버로부터 제안을 받았을 수 있으며, 그 중 하나를 선택
        4. DHCP Acknowledgement
          • DHCP 서버는 DHCP Acknowledgement 메시지를 통해 IP 주소 할당을 확정하고, 필요한 기타 네트워크 구성 정보(서브넷 마스크, 기본 게이트웨이, DNS 서버 주소)를 클라이언트에게 전달

    • DHCP에서 UDP를 사용하는 이유가 무엇인가요?

      • 답
        • 네트워크 장비 초기화 과정에서 일어나기 때문에 네트워크 구성 정보를 효율적으로, 빠르게 구성할 수 있는 UDP 사용

    • DHCP에서, IP 주소 말고 추가로 제공해주는 정보가 있나요?

      • 답
        • 서브넷 마스크, 디폴트 게이트웨이, IP 주소 임대 시간, DNS 정보 등을 제공해줌

    • DHCP의 유효기간은 얼마나 긴가요?

      • 답
        • 유효기간은 DHCP 서버에서 설정된 값에 따라 다르지만, 일반적으로 몇 시간에서 몇 일까지인 경우가 많음
        • DHCP의 기본 임대 기간은 하루(24시간)
        • 네트워크 상황에 따라 임대 기간을 다르게 설정할 수 있음 ⇒ 요청이 많은 곳은 짧은 시간으로 설정하고, 요청이 적은 곳은 긴 시간으로 유연하게 유효기간을 설정함

  • 9. IP 주소는 무엇이며, 어떤 기능을 하고 있나요?

    • 답

      IP

      • 컴퓨터 네트워크에서 장치들이 서로를 인식하고 통신을 하기 위해서 사용하는 고유한 주소
      • 크게 IPv4와 IPv6 2가지 버전으로 나뉨
      • IP 기능
        1. 식별 기능
          • 네트워크 내의 각 기기에 고유한 식별자를 제공
        2. 위치 지정 기능
          • 데이터 패킷이 올바른 목적지로 전송될 수 있도록 기기의 위치를 지정함
        3. 네트워크 인터페이스 구분
          • 하나의 기기가 여러 네트워크에 연결되어 있을 때, 각 연결마다 고유한 IP 주소를 통해 구분 될 수 있음
        4. 데이터 전송
          • 인터넷을 통해 데이터를 전송할 때, IP 주소는 소스와 목적지 주소로 사용되어 데이터 패킷이 올바르게 라우팅 되도록 함

    • IPv6는 IPv4의 주소 고갈 문제를 해결하기 위해 만들어졌지만, 아직도 수많은 기기가 IPv4를 사용하고 있습니다. 고갈 문제를 어떻게 해결할 수 있을까요?

      • 답

        • 공인 IP와 사설 IP로 나누고 중간 NAT이라는 기술을 통해 해결

          ** NAT

          사설 네트워크에서 사용되는 사설 IP 주소를 인터넷에 연결된 단일 공용 IP 주소로 변환 → 여러 기기가 하나의 공용 IP 주소를 공유하여 인터넷에 접속할 수 있게 함 → 공용 IP 주소의 사용을 최소화 함

    • IPv4와 IPv6의 차이에 대해 설명해 주세요.

      • 답

        차이점

    • 수많은 사람들이 유동 IP를 사용하고 있지만, 수많은 공유기에서는 고정 주소를 제공하는 기능이 이미 존재합니다. 어떻게 가능한 걸까요?

      • 답

        DHCP 서버 기능을 끄거나, IP주소를 수동으로 할당하거나 동적 DNS 서비스를 이용한 경우 공유기에서 고정 IP 주소를 제공할 수 있음

        1.DHCP 서버 기능 끄기

        • 대부분의 공유기는 DHCP 서버 기능을 제공합니다. 이 기능은 공유기에 연결된 기기들에게 자동으로 IP 주소를 할당하는 역할을 함

        • 공유기에서 DHCP 서버 기능을 끄면, 공유기에 연결된 기기들은 고정 IP 주소를 사용하게 됨

          2.IP 주소 수동 할당

        • 공유기의 설정 페이지에서 IP 주소를 수동으로 할당할 수 있음

        • IP 주소는 네트워크 관리자가 직접 설정해야 하며, 할당된 IP 주소는 기기가 공유기에 연결되어 있는 동안 유지됨

          3.동적 DNS(DDNS) 서비스 이용

        • 유동 IP를 사용하는 환경에서 공유기에 연결된 기기들이 고정 IP 주소를 사용하는 것처럼 동작하게 하는 서비스

        • DDNS 서비스를 이용하면, 유동 IP 주소가 변경되더라도, 도메인 이름을 통해 기기에 접근할 수 있음

    • IPv4를 사용하는 장비와 IPv6를 사용하는 같은 네트워크 내에서 통신이 가능한가요? 가능하다면 어떤 방법을 사용하나요?

      • 답 IPv4와 IPv6는 서로 호환되지 않는 프로토콜로 기본적으로는 직접 통신할 수 없음 하지만, 두 프로토콜 간의 통신을 가능하게 하는 여러가지 전환 기술이 존재함
        1. 듀얼 스택(Dual Stack)
          • 듀얼 스택 환경에서는 네트워크 장비가 IPv4, IPv6 두 프로토콜을 동시에 지원
          • 장비가 IPv4, IPv6 주소를 모두 가지고 있어 양쪽과 통신할 수 있게 됨
        2. 터널링(Tunneling)
          • IPv6 패킷을 IPv4 네트워크를 통과시키기 위해 IPv6 통신을 IPv4 패킷 안에 캡슐화 함
          • 목적지에서 다시 IPv6 패킷으로 추출
        3. 프로토콜 변환(Protocol Translation)
          • IPv4와 IPv6 네트워크 간의 게이트웨이에서 사용
          • Pv4 패킷과 IPv6 패킷 간의 상호 변환을 수행하여, 두 네트워크 간의 통신을 가능하게 함
          • NAT64는 IPv6 주소를 IPv4 주소로 변환하고, DNS64는 IPv6-only 시스템이 IPv4 주소를 가진 호스트에 접근할 수 있도록 도와줌

    • IP가 송신자와 수신자를 정확하게 전송되는 것을 보장해 주나요?

      • 답
        • IP 자체는 송신자로부터 수신자까지 데이터가 정확하게 전송되는 것을 완전히 보장하지 않음
        • IP는 비연결형 프로토콜이며, 패킷의 순서보장, 무결성 검증, 재전송 등을 직접 처리하지 않음

    • IPv4에서 수행하는 Checksum과 TCP에서 수행하는 Checksum은 어떤 차이가 있나요?

      • 답

        차이점

        1. 적용범위

          • IPv4 체크섬은 IP 헤더에만 적용되며, TCP 체크섬은 TCP 헤더와 데이터 모두에 적용됨

        2. 목적

          • IPv4 체크섬은 패킷 헤더의 무결성을 확인하는 데 중점을 두고, TCP 체크섬은 전송된 데이터 전체의 무결성과 정확성을 검증

        3. 동작 방식
          - IPv4 패킷은 라우터를 거칠 때마다 헤더 체크섬이 재계산되고 검증되는 반면, TCP 체크섬은 송신지와 수신지에서만 계산되어 전체 데이터의 무결성을 확인함

          IPv4 체크섬

        • IPv4 헤더 체크섬은 패킷의 헤더만을 대상으로 함

        • IPv4 체크섬은 패킷의 전송 과정에서 헤더 정보의 무결성을 보장하는 데 초점을 맞춘다. 만약 체크섬이 일치하지 않는 경우, 패킷은 손상되었다고 간주되어 폐기됨.

        • IPv4 체크섬은 헤더 정보만을 검증하므로, 패킷의 데이터 부분(페이로드)에 대한 무결성 검증은 제공하지 않음

          TCP 체크섬

        • TCP 체크섬은 TCP 세그먼트의 전체(헤더 + 데이터)에 대해 계산됨
          → 데이터의 무결성 뿐만 아니라, 전송 순서와 데이터의 완전성까지도 검증하는 데 도움을 줌

        • TCP 체크섬은 세그먼트가 수신지에 도달했을 때 전체 세그먼트를 대상으로 다시 계산되며, 송신 시와 비교하여 검증함

          →데이터가 네트워크를 통해 정확하게 전송되었는지 확인할 수 있음

        • TCP 체크섬은 페이로드 무결성을 보장하기 때문에, 데이터가 손상되었을 경우 재전송을 요청할 수 있음

    • TTL(Hop Limit)이란 무엇인가요?

      • 답
        • IPv4에서는 TTL이라 하고, IPv6에서는 홉 제한(Hop limit)이라고 함
        • 데이터 패킷이 네트워크 상에서 살아남을 수 있는 시간 또는 거쳐갈 수 있는 최대 홉 수를 나타냄

    • IP 주소와 MAC 주소의 차이에 대해 설명해 주세요.

      • 답
        • IP주소는 소프트웨어적으로 할당된 논리적 주소로 변경이 가능함
        • MAC주소는 하드웨어 고유하게 할당된 물리적 주소로 일반적으로 변경 불가능

해당 글은 보초님 깃허브의 질문을 토대로 작성된 글입니다.

출처
쿠키(Cookie)와 세션(Session)
쿠키와 세션 개념
[HTTP] HTTP 메소드의 멱등성(Idempotence)과 Delete 메소드가 멱등한 이유
Http Method 란? (GET, POST, PUT, DELETE)
[HTTP] GET, POST, PUT, PATCH 차이
[HTTP] GET vs POST, GET은 body 값을 가지면 안 될까?
HTTP GET 메소드와 body
HTTP란 무엇인가?
대칭키 vs 공개키(비대칭키)
HTTPS 도대체 왜 쓰는 거야? | HTTPS, SSL Handshake
SSL과 TLS: 차이점, 비교 등!
웹소켓과 소켓은 어떻게 다른가
Network: 소켓(Socket)과 웹소켓
[Network] 소켓과 포트의 의미와 차이점
CS공부 - 네트워크 - 2
[네트워크] HTTP/1.1, HTTP/2.0, HTTP/3.0

profile
gom
탐험하는 개발자
다음 포스트

[CS Study] Network Part.2

0개의 댓글

관련 채용 정보