Lock을 다음 주제로 넘어가기 전에 일반 데이터 구조에 Lock을 얹어 쓰는 방법을 다룹니다. 모든 상황에 두루 통하는 방법을 찾기 어렵기 때문에 시나리오별로 나누어 살펴봅니다. 이번 챕터는 자료 구조라서 학습을 위해 파이썬(표준 라이브러리 threading)으로 같은 패턴을 옮겨 적습니다. ...

동시성 프로그래밍에서 일련의 명령을 원자적으로 실행하고 싶지만, 단일 또는 멀티 프로세스에서 멀티 스레드 환경을 도입시 프로세서에서의 인터럽트가 발생하기 때문에 그렇게 할 수 없죠, 그래서 이장에서 Lock을 도입하여 문제를 해결합니다. 해당 글에서도 c가 아닌 python으로 코드를 적습니다.(컨샙이나 이해부분을 위해 OSTEP를 보는 것이죠) 하지만 포인터 개념이 필요한 경우 c 코드를 참고합니다. ...

교재에서는 c의 POSIX을 기반으로 진행되고 있고 Python을 공부 중이므로 Python의 threading로 해당 글을 진행합니다. threading 모듈은 OS의 저수준 스레딩 기능 위에 구축된 객체 지향 API로 Unix 계얼에서는 POSIX Thread(pthreads) 라이브러리를 기반으로 동작합니다. Thread Creation 파이썬에서는 threading.Thread 객체를 만들어 스레드를 생성합니다. 핵심은 “어떤 함수를 어떤 인자로 실행할지"를 스레드 객체에 넘기고, start()로 실행을 시작하는 흐름입니다. ...

Process vs Thread 멀티 스레드는 하나의 Program Counter(PC)만 갖는 단일 스레드와 달리 각 스레드가 자신만의 Program Counter(PC)와 스택(Stack) 을 가집니다. 이로 인해 멀티 프로세스와 달리 다음 차이점들이 발생합니다. ※ Program Counter(PC): 다음에 실행할 명령어의 주소를 저장하는 레지스터 하나의 프로세스에 두 개의 스레드(T1, T2)가 있다고 가정해보면, T1에서 T2로 넘어갈 때 스레드 간 컨텍스트 스위치가 일어납니다. 이 과정은 프로세스 간 컨텍스트 스위치와 비슷하게 현재 실행 상태를 저장하고 다음 실행 상태를 복원한다는 점에서 유사합니다. ...

서론 해당 글은 Laravel, Spring, Gin 등 다양한 프레임워크를 사용해 본 입장에서 Django를 살펴보며 정리한 메모입니다. Django 6.0 기준으로 Introduction은 다음과 같이 구성되어 있습니다. Django 훑어보기 빠른 설치 가이드 장고 앱 작성하기, part 1 ~ 8 심화 튜토리얼: 재사용 가능한 앱을 만드는 법 다음에 읽을 내용 장고에 처음으로 기여하기 Django 훑어보기 튜토리얼이 아닌 제목 그대로 Django의 동작 방식에 대해 설명하고 있습니다. ...

OAuth OAuth 2.0은 인증(Authentication) 자체보다 권한 부여(Authorization) 를 위한 프레임워크입니다. 즉, 제3자 애플리케이션이 리소스 소유자의 비밀번호를 직접 받지 않고도, 제한된 범위(scope)의 접근 권한을 얻도록 설계되었습니다. 네이버/카카오/구글 로그인에서 자주 보이는 흐름도 이 개념을 기반으로 하지만, “로그인(신원 확인)” 자체는 보통 OpenID Connect(OIDC) 같은 상위 프로토콜이 함께 쓰입니다. ...

서론 서버가 교차 출처 요청을 아무 기준 없이 허용하면, 민감한 응답 데이터가 의도치 않게 노출될 수 있습니다, 브라우저는 Same-Origin Policy를 기본으로 적용하고, 서버는 CORS 헤더를 통해 특정 Origin에 한해 접근을 허용하는 방식으로 이를 대응합니다. Same-Origin Policy: 웹 브라우저가 보안을 위해 한 출처(Origin)에서 가져온 문서나 스크립트가 다른 출처의 리소스와 상호작용하는 것을 제한하는 핵심 보안 메커니즘 CORS: 브라우저가 다른 도메인(출처)의 서버 자원에 접근할 때, 보안상 제한(동일 출처 정책, SOP)을 해제하고 합법적으로 데이터를 공유하도록 서버가 허가해 주는 HTTP 응답 헤더 기반 메커니즘 Origin의 정의와 직렬화, 그리고 HTTP Origin 헤더를 규정한 RFC 6454를 정리합니다. Origin 개념을 이해하면 다른 출처 접근이 어떤 기준으로 허용/차단되는지, 그리고 이를 통해 서버 자원을 어떻게 보호하는지 명확하게 볼 수 있습니다. ...

서론 HTTP/3는 구글에서 QUIC로 개발하였고 22년 6월에 RFC 9114로 표준화되며 HTTP/3로 변경되었습니다, 참고로 HTTP/3의 기반이 되는 QUIC는 새로운 전송 프로토콜로 RFC 9000으로 표준화되었죠. ※QUIC(Quick UDP Internet Connections): UDP 기반의 차세대 전송 프로토콜로, TCP를 쓰지 않아 TCP 수준의 HOL(head-of-line) 블로킹을 줄일 수 있음 HTTP/3의 필요성 QUIC를 사용함으로써 HTTP/2의 가장 큰 단점 몇 가지를 해결할 수 있습니다. ...

서론 HTTP/1에서 HTTP/1.1로 업데이트되면서 많이 바뀌습니다만, 아직 남은 이슈들을 HTTP/2이 개발되었고 여기에는 프레임, 멀티플렉싱 등이 추가되었죠. HTTP/1 문제점들 HTTP/1에서 HTTP/1.1로 업데이트하면서 HTTP Pipelining이 추가되었지만, 이 HTTP Pipelining에서 동시성 문제가 발생했습니다. HTTP Pipelining은 HTTP/1.1에서 응답 순서 보장을 위해 사용되었는데, 이 때문에 요청이 연달아 들어오면 서버는 요청 순서대로 응답해야 하는 특징이 있어 뒤 요청은 대기 상태가 되는 문제가 생깁니다. ...

개요 1-1. Go 동시성, 정말 장점일까? - 주요 언어 성능 비교 GoLang의 사용처를 묻는 질문이 들어온다면 블록체인, 게임서버, 네트워크, 실시간 데이터 처리, 고성능 API 등 중에서 아마 대답이 나올 겁니다. 결국 고루틴(goroutine) 기반의 강력한 동시성을 GoLang의 핵심으로 보고 이를 장점으로 이야기 하는 것이죠. 이는 GoLang에 대해 공부하면 경량화된 쓰레드 자체 특징에 더해 채널, 락관리 등도 매우 편리하게 할 수 있는 걸 알고 있죠. ...