티스토리

테오의 학습기록

검색하기

블로그 홈

테오의 학습기록

dev-ws.tistory.com/m

우아한테크코스 5기 테오입니다.

구독자: 9

방명록 방문하기

주요 글 목록

HTTP/1.1와 비교하면서 알아보는 HTTP/2 HTTP/1.1과 HTTP/2HTTP/2는 HTTP/1.1과 어떤 점이 다른지 알아보기에 앞서, 왜 HTTP/2가 등장하게 되었는지를 먼저 이해하도록 하자. HTTP의 유래는 하이퍼텍스트 전송으로, 실은 논문을 전송하기 위해 만들어진 프로토콜이다. 즉, 텍스트로 구성된 문서 전송에 있어서 최적화된 프로토콜이라는 것이다. 하지만 최근의 웹 서비스를 살펴보면, 단순히 문서 교환을 위해 HTTP가 사용되는 것이 아니라, 이미지나 비디오와 같은 다양한 포맷의 정보를 전송하는 경우가 많아졌다. 즉, 요구사항이 시대의 흐름을 따라 변화하였다는 것인데, 기존의 HTTP/1.1로는 이러한 요구사항을 대응하기가 어려워졌다. 가장 큰 문제는 성능이었는데, 대표적으로는 헤더를 예시로 들 수 있겠다. HTTP 메세지의 경우 .. 공감수 0 댓글수 0 2024. 6. 16.
gRPC basic concepts Remote Procedure CallgRPC는 구글에서 개발한 프레임워크다. 따라서 앞에 'g'가 붙은 것임을 유추할 수 있을 것이다. 그렇다면 RPC는 무엇인가? gRPC라는 개념을 알아보기에 앞서 RPC(Remote Procedure Call)에 대해 이해해보자. RPC는 직역하면 원격 프로시저 호출로, 다른 주소 공간에서 함수나 프로시저를 실행할 수 있게 하는 프로세스 간 통신 기술이다. 쉽게 말해, 다른 컴퓨터나 프로세스에 있는 함수를 마치 내 것인것 마냥 원격으로 호출할 수 있다는 것이다. 기본적으로 RPC는 네트워크 기반으로 동작하도록 설계되었다. 즉, 원격으로 내 컴퓨터에 있는 다른 프로세스의 함수를 호출하는 것이 1순위 목적이 아니라, 네트워크를 타고 다른 노드에 있는 함수를 호출하는 .. 공감수 0 댓글수 1 2024. 5. 22.
ZeroMQ & basic ZeroMQ Patterns 선조의 개발자들은 클라이언트나 서버를 구현하기 위해 Berkeley Sockets와 같은 Socket API를 사용해 프로그램을 작성했을 것이다. 다만 Socket API의 경우 운영체제와 바로 맞닿아 있는 부분이기에, 저수준의 지엽적인 내용이 많고 사용하기가 복잡하다. 따라서 자주 발생하는 부분은 패턴으로 정의하고, 추상화하고자 하는 니즈가 자연스레 생겨났다. 그 결과 전송 계층 위에서 네트워크를 제어할 수 있는 소프트웨어들이 등장하게 되었고, ZeroMQ는 그러한 소프트웨어 중 하나이다. ZeroMQ 소개 ZeroMQ는 분산 어플리케이션이나 동시처리 어플리케이션에서 활용할 수 있는 고성능 비동기 메세징 라이브러리이다. 다만 이 말의 뜻을 개인적으로는 이해하기 어려워서 추가적으로 조사해봤다. 분산 어플.. 공감수 1 댓글수 0 2024. 4. 20.
TCP Error Control 앞서 TCP의 흐름 제어, 혼잡 제어를 살펴봤다. 이외에도 TCP는 오류 제어라는 기법을 사용하는데, 이번 글에서 어떻게 TCP가 오류에 대한 제어를 수행하는지 살펴본다. 우선 오류 제어가 무엇인지, 왜 필요한지 당위성부터 알 필요가 있다. TCP는 Survivalability가 중요한 프로토콜이다. 신뢰성 있는 통신을 지향하며, 가능한 효율적으로 작동한다. 통신은 오류가 발생할 수 있다. 잡음이 발생해 패킷이 손상되거나, 순서가 잘못되었거나, 버려지는 등 항상 의도한대로 동작할 순 없다. 따라서 이러한 오류가 발생했을 때 적절히 대처하는 방법이 필요한데, 그것이 오류 제어다. TCP 오류 제어는 여러 기법들을 사용해서 진행된다. 크게는 총 3가지 기법을 사용한다고 말할 수도 있는데, 체크섬, ACK, .. 공감수 0 댓글수 0 2024. 4. 11.
TCP Congestion Control 혼잡 제어(Congestion Control)은 안정적인 네트워크 구축을 위해 필요한 기능이다. 인터넷을 비롯한 모든 네트워크는 하드웨어적 한계가 존재하므로 감당할 수 있는 용량이 정해져 있다. 이러한 용량을 초과하는 경우, 높은 대기 시간, 연결 시간 초과 및 패킷 손실과 같은 현상들이 발생하게 된다. 네트워크를 사용하는 입장에서는 이러한 정체가 발생하는 것을 좋아하진 않을 것이다. 또한 이러한 상황이 계속 누적되어 네트워크 정체가 점점 악화될 수도 있는데, 이를 혼잡 붕괴(Congestion Collapse)라고 부르기도 한다. 따라서 정체가 발생했다면 전송하는 패킷의 수를 줄이는 등의 작업이 필요하다. 그리고 이러한 관리 기법을 혼잡 제어(Congestion Control)이라고 한다. TCP의.. 공감수 0 댓글수 0 2024. 4. 8.
TCP flow control TCP(Transmission Control Protocol)에는 크게 세 가지 제어 기능이 존재한다. 하나는 전송되는 패킷의 양을 조절하는 흐름제어, 하나는 패킷이 잘 도착했는지를 확인하고 오류가 발생했을 때 재전송할 수 있게 해주는 오류제어, 마지막 하나는 네트워크의 혼잡을 피하기 위한 혼잡제어다. 이번 아티클에서는 그 중 흐름제어에 대해 살펴본다. 각각 양이 많아 오류제어와 혼잡제어는 추후 다른 아티클로 작성하겠다. 흐름제어(flow control)통신에서 주로 활용하는 기술이 버퍼다. 이는 여러 요소(장치, 프로그램)등이 처리하는 속도나 크기, 단위가 다르기 때문이다. 따라서 어떠한 완충기 역할을 하는 버퍼를 둬서 통신하게 된다. 우리가 사용하는 PC도 네트워크 통신을 위한 NIC(Network .. 공감수 3 댓글수 3 2024. 3. 29.
CSMA/CD, CSMA/CA 이더넷에서는 충돌이 발생할 수 있다. 특히 과거에 충돌이 발생하는 경우가 많았는데, 주로 다음의 Bus topology와 같이 유선 케이블을 공유하는 과정에서 발생했다고 한다. 위와 같이 하나의 회선을 여러 디바이스가 공유하는 구조라면, 송수신에 대한 제약이 생길 수 밖에 없다. 이런 상황에서 여러 디바이스가 동시에 데이터를 송신하게 되면, 물리적 신호가 겹치게 되고 이를 '충돌이 발생했다' 라고 표현한다. 따라서 위와 같은 충돌을 해결하기 위해 존재하는 이더넷 표준이 CSMA/CD이다. 다만 미리 알아두어야 할 것은, CSMA/CD는 현재보다는 과거에 주로 사용했던 기술이라는 점이다. 최근은 허브와 같은 장비들을 사용하지 않고 스위치를 주로 사용하면서 네트워크의 형태가 bus topology에서 sta.. 공감수 2 댓글수 1 2024. 3. 26.
Software Defined Networking(SDN) SDN은 말 그대로 '소프트웨어로 정의된 네트워킹 방식'을 의미한다. 기존의 네트워킹 방식, 우리가 흔히 알고 있는 네트워킹 방식은 물리적인 장비들이 '스스로' 데이터를 전송하는 방식이다. 우리의 PC는 네트워킹이 어떤 방식으로 이루어지고 있는지, 어느 라우터를 거치는지 등을 알지 못하지만 패킷을 송, 수신할 수 있다. 이는 스위치나 라우터 같은 장비들이 스스로 목적지를 판단하고 패킷을 포워딩하기 때문이다. SDN는 반대로 이 데이터의 흐름 자체를 제어하는 데에 목적이 있다. 전통적인 방식과는 다르게 네트워크 장비의 제어부만 분리해서 이를 별도의 컨트롤러로 이전한다. 그러니까, SDN을 적용한 네트워크 장비들은 포워딩만 할 뿐, '어떻게 가지?'등과 같은 내용은 컨트롤러가 담당한다는 것이다. 컨트롤러에서.. 공감수 0 댓글수 0 2024. 3. 23.
Broadcast Domain & Collision Domain 현재 AIoT 수업을 듣고 있는데, Broadcast Domain과 Collision Domain이라는 용어가 자주 등장하는 것 같다. 이번 포스팅에서는 이들이 어떤 개념을 갖고 있는지 알아보면서 이더넷 네트워크에 대한 약간의 기초 개념까지 잡아보자. Collision Domain Collision Domain을 직역하면 충돌 도메인이라는 의미이다. 이는 네트워크에서 '패킷이 충돌하여 영향을 받게 되는 영역'을 의미하는데, 이더넷 네트워크는 하나의 회선을 여러 종류의 패킷이 사용할 수 있는 구조이기 때문에 충돌 가능성이 존재하기 때문이다. 전통적인 이더넷은 이러한 충돌에 대한 해결책으로 CSMA/CD 방식을 사용한다. CSMA/CD란 Carrier Sense Multiple Access with Coll.. 공감수 2 댓글수 2 2024. 3. 17.
HTTP 요청 및 응답 구조 알아보기 이번 아티클에서는 HTTP 요청과 응답이 어떤 구조를 가지는지 알아보도록 하겠습니다. HTTP 메세지 구조 HTTP 요청(Http Request), HTTP 응답(Http Response) 모두 HTTP 메세지입니다. 표준에서 정의하는 HTTP 메세지의 구조는 다음과 같습니다. 보시다시피 HTTP 메세지는 크게 네 가지 부분으로 구성됩니다. start line, message headers, CRLF, message body입니다. start line start line의 경우 HTTP 메세지에서 가장 처음에 위치하는 부분입니다. 그리고 start line은 HTTP 요청이냐, 응답이냐에 따라 두 가지 종류로 나뉘게 됩니다. HTTP 요청인 경우에는 request line이라는 이름으로 불리며, HTTP.. 공감수 0 댓글수 2 2023. 9. 4.
Oauth의 등장 배경 및 개념 이해해보기 이번 아티클에서는 Oauth의 개념을 알아보고 어떻게 인증 플로우를 구성할 수 있는지 알아보겠습니다. Oauth의 등장 배경 Oauth에 대해 알아보기에 앞서, 왜 등장했는지부터 이해해봅시다. Oauth가 등장하기 이전에는 인증방식에 대한 표준이 존재하지 않았습니다. 따라서 각 서비스마다 자체적으로 아이디 비밀번호를 관리하는 형태였습니다. 이런 상황에서 서비스 간에 정보를 공유해야 하는 상황이 생겼다고 가정해봅시다. 예를 들어 사용자의 일정 관리를 도와주는 A라는 서비스가 있는데, A 서비스에서는 보다 수월한 일정 관리를 위해서 사용자의 '구글 캘린더' 정보를 필요로 합니다. 이 때, 어떻게 사용자의 구글 캘린더 정보를 받아올 수 있을까요? A라는 서비스에서는 해당 유저에 대한 구글 계정 정보를 모르는데.. 공감수 4 댓글수 0 2023. 8. 15.
대칭키 vs. 비대칭키(feat. 공개키, 개인키) 프로젝트에 JWT를 도입하면서 암호화에 대한 개념도 접하게 되었지만, 용어 정리가 명확하게 되지 않아 헷갈리는 일이 많았습니다. 따라서 이번 아티클에서는 공개키와 개인키, 그리고 대칭키와 비대칭키에 대해 정리해보고자 합니다. 대칭키 대칭키란 어떤 정보를 암호화, 혹은 복호화할 때 사용하는 키가 동일한 경우입니다. 대칭키 암호화 방식을 사용하는 경우, 어떤 정보가 A라는 키로 암호화 되었다면 수신하는 쪽에서도 동일하게 A라는 키로 복호화해야 합니다. 대칭키 방식은 암호화 / 복호화 과정에 있어 속도가 빠르다는 장점이 있으나, 키를 안전하게 교환해야 하는 문제점을 가지고 있습니다. 키를 가진 누구나 암호화 / 복호화가 가능하기 때문에 탈취되었을 때의 위험도가 크기 때문입니다. 따라서 많은 암호화 통신에서 뒤.. 공감수 0 댓글수 0 2023. 8. 12.

문의안내

티스토리
로그인
고객센터

티스토리는 카카오에서 사랑을 담아 만듭니다.