ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • CS 스터디 - 네트워크 Q&A (1)
    CS 2023. 8. 3. 12:55

    4주가량의 스터디 동안 프레젠테이션 방식으로 돌아가면서 CS의 큰 주제에 대해 발표하는 시간을 가졌다. 

    스터디 모임때마다 각자 문제를 만들어오고 돌아가면서 답변하는 Q&A 방식으로 새롭게 진행중이다. 매주 긴장중... 

     


    #1 ) HTTP 메소드인  PUT과 PATCH의 차이점에 대해 설명해주세요. 

    - 자원에 모든 상태(필드)에 대한 값을 대입하지 않은 경우 PUT 메소드는 오지 않은 값에 NULL을 대입하여 변경합니다.

    반면 PATCH의 경우, 오지 않은 값은 기존 값 그대로 두고 바뀐 부분만 변경합니다. 

    - 요청한 URI에 자원이 존재하지 않는 경우 PUT 메소드는 새롭게 자원을 생성하고, PATCH는 존재하지 않는다는 메시지를 리턴합니다. 

    - 멱등성 관점에서, PUT은 멱등성을 가지고 PATCH는 멱등성을 가지지 않습니다. (정확히는 가지게 설계할수도, 가지지 않게 설계할 수도)

     

    * PATCH 메소드를 PUT처럼 요청 BODY에 덮어쓸 내용만 포함한 경우 멱등성을 가질수도 있다. 하지만 아래 접은글처럼 동작을 지정해줄수도 있는데, 이 경우 멱등성을 가지지 않는다. PATCH 메소드가 HTTP 스펙 상 구현 방법에 제한이 없어서 요청 바디에 꼭 덮어쓸 데이터가 있어야만 하는 것은 아니므로, 동작을 지정해줄 수 도 있다. 

     

    더보기

    * PATCH는 멱등으로 설계할 수도 있지만, 멱등이 아니게도 설계할 수 있습니다.

    예를들어서 다음과 같은 경우는 PATCH 이지만 멱등입니다.

    { name: "kim"}

    반면에 다음과 같은 경우는 PATCH 이지만 멱등이 아닙니다.

    예를 들어서 한번 호출할 때 마다 나이를 10 더하는 식으로 변경하고 싶다고 가정하겠습니다.

    PATCH는 멱등이 아니기 때문에 다음과 같이 특정 부분을 추가로 더하거나 하는 식으로 설계해도 됩니다. 물론 이 경우 서버에서 operation add가 어떤 의미인지 알 수 있어야 합니다.

    { "operation": "add", "age": 10"}

    이렇게 하면 2번 호출하면 +10 + 10이 되어 버려서 먹등이 아닙니다.

    정리해드리면 PATCH는 리소스의 특정 부분을 변경하는데, 이 변경 방식이 멱등이어도 되고, 멱등이 아니어도 됩니다.

     

    * put의 경우 원래 정상 목적자체가 그냥 데이터를 넣어달라는 요청이기에, 정상적으로 사용한다면 멱등이며, patch처럼 사용을 했다면, 그 목적대로 사용하지 않았기 때문에 멱등이 되지 않을 수 있으나,

    잘못 사용한 것에 대해서는 고려하지 않는 것 같습니다.

     

     

    - 인프런 Q&A

     

    * 멱등성

    - 첫 번째 수행을 한 뒤 여러 차례 적용해도 결과를 변경시키지 않는 작업 또는 기능의 속성

    - 멱등한 작업의 결과는 한 번 수행하든 여러 번 수행하든 같습니다. 

    - 참고로 서버의 상태코드 (200, 204 등)가 다르더라도 서버 상태 동일하면 멱등성 가진다고 판단.  

     

     

    #2 ) HTTP 1.0에서 HTTP1.1로 발전하며 어떤 점이 달라졌나요? 

    - 매번 TCP 연결을 하는 것이 아닌, 한 번 TCP초기화를 한 이후 keep-alive 옵션으로 여러 개 파일 송수신 가능(이전에도 있었지만 1.1에서 표준화되어 기본 옵션으로 설정됨)  = 즉, 연결이 이루어진 뒤 각각의 자원을 요청하고, 모든 자원에 대한 응답이 돌아온 후에 연결을 종료하는 방식을 기본으로 채용 

    - 파이프라이닝 : 첫번째 요청에 대한 응답이 완전히 전송되기 이전에 두번째, 세번째 요청 전송을 가능하게 한다. 

     

     

     

    #3 ) HOL Blocking 현상에 대해 설명해주세요.

    네트워크에서 같은 큐에 있는 패킷이 그 첫 번째 패킷에 의해 지연될 때 발생하는 성능 저하 현상을 의미합니다. 뒤에 있는 패킷이 먼저 끝나더라도 앞의 패킷 지연으로 인해 전송되지 못하는 현상을 의미합니다. HTTP1.X 버전까지의 문제점이었으며, HTTP2에서 멀티플렉싱 (여러 개의 스트림을 사용하여 송수신) 통해 이를 해결하였습니다. 

     

    + ) HTTP/2.0 관련 추가 

     

    - H2의 핵심은 바이너리 프레이밍 계층을 사용해 요청과 응답의 멀티플렉싱을 지원, HTTP 메시지를 바이너리 형태의 프레임으로 나누고 이를 전송 후 받은 쪽에서 다시 조립한다. 

    - 하나의 연결에 응답 / 요청 섞여있음  === 여러개의 커넥션 없이 하나의 커넥션으로 병렬 처리 가능 / 서버가 필요한 리소스 미리 푸시하는것도 가능 

     

     

    #4 ) 가상회선 패킷교환 방식 VS 데이터그램 패킷 교환 방식? 

    2가지 모두 패킷 교환 방식이다. 패킷 교환 방식이란, 메시지를 패킷이라는 작은 단위로 쪼갠 후 주소를 붙여 전송하는 방식이다. 

     

    가상회선 패킷 교환 방식 : 패킷이 전송되기 전에 송수신 측 간에 하나의 회선을 설정, 회선 교환 방식과는 달리 회선이 독점되지 않고 공유되며 설정된 경로를 통해서 송신된 데이터들은 순서에 맞게 수신측에 전달된다. 

     

    데이터그램 패킷 방식 : 패킷이 독립적으로 전송되고 패킷을 수신한 라우터는 최적의 경로를 찾아서 패킷을 목적지로 전송, 동일 목적지 패킷이어도 다른 경로로 전송될 수 있음, 송신 측 순서와 수신 측 순서가 다를 수 있다. 

     

     

    # 5 ) HTTP vs HTTPS 비교 

    HTTP는 암호화가 되지 않은 평문 데이터를 전송하는 프로토콜이므로, HTTP의 데이터를 제3자가 도청 가능하다는 문제점이 있었습니다. 

    HTTPS는 HTTP 데이터에 암호화가 추가된 프로토콜로, SSL/TLS라는 암호화 프로토콜을 이용하여 통신 내용을 암호화합니다. 

    80번 포트를 사용하는 HTTP와 달리 443 포트를 사용하고, 처음 연결 시에는 비대칭키 암호화를 사용하고, 데이터를 주고 받을 때에는 대칭 키 암호화 사용하여 빠른 동작속도 + 안정성을 확보합니다. 

    https://mangkyu.tistory.com/98

     

    [Web] HTTP와 HTTPS의 개념 및 차이점

    1. HTTP란? [ HTTP(Hyper Text Transfer Protocol)란? ] HTTP(Hyper Text Transfer Protocol)란 서버/클라이언트 모델을 따라 데이터를 주고 받기 위한 프로토콜이다. 즉, HTTP는 인터넷에서 하이퍼텍스트를 교환하기 위

    mangkyu.tistory.com

     

    더보기

    추가로 HTTPS 구축 방법

    - 직접 CA에서 구매한 인증키를 기반으로 HTTPS 서비스 구축

    - 서버 앞단에 HTTPS 제공하는 로드밸런서 두기

    - 서버 앞단에 HTTPS 제공하는 CDN 두기 

     

     

    # 6 ) 쿠키-세션방식과 비교하여 토큰 인증방식이 가지는 장점이 어떤것이 있나요?

    - 쿠키-세션 방식과 달리 토큰 자체가 인증에 필요한 정보를 가지고 있기 때문에 따로 서버의 관리가 필요하지 않으며, 클라이언트가 토큰을 저장하고 있으므로 CORS 이슈로부터 자유로우며 확장성이 좋다는 장점이 있습니다. 

    더보기

     세션도 결국 쿠키를 사용하기 때문에 역할, 동작 원리가 거의 비슷, 차이점이라면 정보가 저장되는 위치, 라이프사이클이다. 

    쿠키 : 서버의 자원 사용 X, 클라이언트 로컬에 저장된다. 변질되거나 탈취 가능성 있지만 속도가 빠름(쿠키에 정보가 있으므로), 라이언트 로컬에 파일로 저장되므로 브라우저 종료해도 정보가 유지된다. 만료기간 따로 지정도 가능 
    세션 : 쿠키 활용해서 session-id만 클라이언트 측에, 나머지 정보들은 서버에 저장, 비교적 보안이 우수하나(세션id털려도 서버측에서 삭제하는 등 무효처리하면 된다) 속도가 느리고, 만료기간과 상관없이 브라우저 종료 시 삭제된다. 

     

     

    # 7 ) CORS가 무엇인가요? 

    -> 교차 출처 리소스 공유(Cross-Origin Resource Sharing, CORS)는 추가 HTTP 헤더를 사용하여, 한 출처에서 실행 중인 웹 애플리케이션이 다른 출처의 선택한 자원에 접근할 수 있는 권한을 부여하도록 브라우저에 알려주는 체제입니다.

     

    - 프로토콜 - 세션 - 포트번호가 모두 같아야 same origin이라고 브라우저가 판독하며, 웹사이트들은 기본적으로 SOP(same orign policy)에 따라 동일 웹 어플리케이션끼리만 자원을 공유한다. 하지만 다른 출처에 있는 자원 가져다 쓰는건 매우 흔한 만큼, 신뢰할 수 있는 사이트처럼 몇가지 예외를 둬서 SOP을 우회한다고 생각하면 된다.

    - 추가로, origin을 비교하는 것은 브라우저의 몫이다. 서버 측에서는 CORS에 위배되어도 200 응답이 가능하나 브라우저가 CORS 위반된다고 판단하면 에러 날린다. 

     

    참고 ) 

    https://seongonion.tistory.com/118?category=931637 

     

    교차 출처 리소스 공유, CORS(Cross-Origin Resource Sharing)에 대하여

    CORS란? 교차 출처 리소스 공유(Cross-Origin Resource Sharing, CORS)는 추가 HTTP 헤더를 사용하여, 한 출처에서 실행 중인 웹 애플리케이션이 다른 출처의 선택한 자원에 접근할 수 있는 권한을 부여하도록

    seongonion.tistory.com

     

     

    # 8 ) UDP의 장점에 대해서 설명해주세요. 

    TCP처럼 3-way handshaking 과정을 진행하지 않으며, 데이터 그램 패킷 교환 방식을 채택, 각 패킷에 순서가 존재하지 않으므로 독립적인 경로로 처리하는 것이 가능하다. 동일 목적지 패킷이어도 그때 그때 최적의 경로를 선택하여 각 다른 경로로 패킷을 전송하는 것이 가능, TCP에 비해 속도가 빠르다.   

     

    +) 가상회선 패킷교환 방식을 통해 패킷 보낸 순서 == 받는 순서 보장하는 TCP와 대조, TCP는 소켓(종단점) 생성하지만 UDP는 IP주소만 

     

    UDP의 헤더에는 출발지와 도착지, 패킷의 길이, 체크섬(최소한의 데이터 상태 체크용으로만 사용함) 정도만 정의되어 있는, 데이터 전송 자체만을 목적으로 만들어져서 TCP에 비해 사용자가 최적화하기에 좀 더 용이하다. 따라서 HTTP/3에서 UDP 기반의 QUIC을 채택한 것이기도 하다.  

     

    추가참고용 : https://evan-moon.github.io/2019/10/08/what-is-http3/

     

    HTTP/3는 왜 UDP를 선택한 것일까?

    는 의 세 번째 메이저 버전으로, 기존의 HTTP/1, HTTP/2와는 다르게 UDP 기반의 프로토콜인 을 사용하여 통신하는 프로토콜이다. HTTP/3와 기존 HTTP 들과 가장 큰 차이점이라면 TCP가 아닌 UDP 기반의 통

    evan-moon.github.io

    추가 )

    넷플릭스나 유튜브처럼 시간에 민감하지 않은, 단일 시청자만을 위한 스트리밍 서비스는 TCP를 사용한다. (캐시 등으로 미리 받아놓거나 하는 등의 조치를 통해 원활한 시청하도록 만듦)

    하지만 ZOOM과 같은 화상회의 솔루션은 여러 참여자간 양방향 전송이 일어나는, 시간에 민감한 서비스들이 UDP를 사용 

     

    #9 ) CDN 이란 무엇인가요?  

     

     

    CDN이란 콘텐츠 전송 네트워크의 약자로, 서버 자체를 여러곳에 두고 이용자가 요청했을때 제일 근접한 서버에서 처리하는 기술입니다. 사용자와 가까운 곳에 데이터 서버를 배포하여 트래픽이 많은 웹 사이트가 빨리 표시되는 등 서비스가 신속히 제공되도록 지원합니다. 

     

     

    # 10 ) 프록시 서버에 대해서 설명해주세요. 

    프록시는 두 PC가 통신을 할 때 직접 하지 않고 중간에서 대리로 통신을 하는 것을 의미하는데,  프록시 서버는 클라이언트와 서버 사이의 ‘중계 서버’를 의미합니다. 

    프록시 서버가 중간에 위치함으로써 클라이언트는 프록시 서버를 ‘서버’라고 인식하고, 서버 입장에서는 프록시 서버를 ‘클라이언트’로 인식하게되며, 클라이언트에서 서버로 요청을 보낼 때 직접 요청하지 않고 프록시 서버를 거쳐 요청하게 됩니다.

    주로 보안, 캐싱 등의 목적으로 사용합니다. 

    • 캐싱 : 정적 데이터 저장해두고 동일 요청인 경우 웹서버까지 가지 않음 
    • IP 우회 : 서버 측은 클라이언트의 IP가 아닌 프록시 서버의 IP를 전달받음. 
    • 사내망 : 정해진 사이트에만 연결할 수 있도록 설정 

    추가 질문 ) 리버스 프록시 (nginx, apache web server) ? 

    위의 정의된 내용은 포워드 프록시(일반적으로 프록시라고 하면 이것을 의미)이다.

    리버스 프록시는 애플리케이션 서버의 앞에 위치하여 클라이언트가 서버를 요청할 때 리버스 프록시를 호출하고, 리버스 프록시가 서버로부터 응답을 전달받아 다시 클라이언트에게 전송하는 역할을 합니다. 

    • 로드밸런싱 : 리버스 프록시 뒤에 여러개의 was를 둠으로써 사용자 요청을 분산, 엔드포인트마다 호출 서버를 설정할 수 있어 역할에 따라 서버 트래픽 분산 가능
    • 보안 : 서버에 직접 접근하는 것을 막기 위해 dmz같은 네트워크에 리버스 프록시 구성하여 접근

     

     

    'CS' 카테고리의 다른 글

    CS 스터디 - Java & Spring  (0) 2023.08.15
    CS 스터디 - 운영체제 Q&A(1)  (0) 2023.08.10
    CS 스터디 - 운영체제  (0) 2023.07.21
    CS 스터디 - 네트워크 이론  (0) 2023.07.05
    CS 스터디 - Spring  (0) 2023.06.20
Designed by Tistory.