[TIL] 기술면접 대비 정리 2 | 내가보려고 간단하게 정리한 글
PEP 8 : 파이썬 코딩 스타일 가이드라인
- PEP (Python Enhance Proposal)
- 파이썬 개선 제안서, 파이썬 코드를 어떻게 구상할 지 알려주는 스타일 가이드
- 원활한 협업을 위한 공유된 스타일
- 일관성 있는 스타일은 수정하기 쉬움
PEP8을 한국어로 번역한 문서사이트 | pep8-in-korean
TIM sort
Insertion sort
(삽입 정렬)와Merge sort
(병합 정렬)를 결합하여 만든 하이브리드 정렬.Tim sort
는 안정적인 두 정렬 방법을 결합했기에 안정적- 파이썬의
sort()
,sorted()
에 사용된 알고리즘- 대부분 파이썬 정렬문제 해결에는 sort(), sorted()가 가장 빠름
- 현업에서 병합정렬, 퀵정렬 보다 더 널리 쓰임
- 파이썬을 위해 C 언어로 구현된 알고리즘이다.
- 기존의 Merge sort에 비해 적은 추가 메모리를 사용하여 다른
O(nlogn)
정렬 알고리즘의 단점을 최대한 극복함 - Python, Java SE 7, Android, Google chrome (V8), swift 등 많은 프로그래밍 언어에서 표준 정렬 알고리즘으로 채택되어 사용
읽어 보기 : https://questionet.tistory.com/61
정렬 알고리즘을 비교한 표
읽어 보기 : d2.naver/helloworld - Tim sort에 대해 알아보자
VPN 🆚 Proxy
온라인 프라이버시와 익명성을 지키기 위한 도구
Proxy(프록시 서버)
- 클라이언트가 다른 네트워크 서비스에 간접적으로 접속할 수 있도록 중계해주는 서버
- 사용자의 인터넷 트래픽을 목표 서버까지 전달하는 가상 통로 역할
- 상대방 입장에서 트래픽은 프록시 서버 주소에서 오는 것처럼 표시됨
- 사용자의 IP와 활동은 프록시 서버 자체에 기록 된다
- 처음엔 인터넷 속도 향상 목적(=프록시 서버에 캐시 저장) 이었으나 현재는 IP우회 도구로 많이 사용
proxy | HTTP 프록시 서버 | SOCKET 프록시 서버 |
---|---|---|
사용 목적 | 가장 간단하면서 기본적인 프록시 서버 유형, 웹 트래픽 (HTTP와 HTTPS) 리다이렉트하는 작업을 함 | 이 서버는 서비스 역량을 웹 검색에 한하지 않음 |
장점 | 오직 HTTP 요청만 처리할 수 있어 속도가 빠름, 간편한 익명 웹 검색 목적에 비용 효과적(무료 웹 프록시 서비스) | SMTP, FTP, 토렌트 같은 HTTP가 아닌 트래픽을 지원 |
단점 | 트래픽 암호화x | 웹 프록시 서버와 같은 보안 문제 발생 가능 |
웹 트래픽 제한 | 웹 프록시 서버보다 느리다 | |
무료 웹 프록시는 보안성이 떨어짐 |
VPN(Virtual Private Network)
- 가상사설망 : 공용망을 사설망처럼 이용하는 것을 말함
- VPN을 이용하면 내 IP가 아닌 VPN서버에서 제공하는 IP로 인식
- VPN에 접속한 컴퓨터와 VPN서버 사이에 지나가는 패킷을 암호화 하는 경우가 많아 VPN서버 로그를 보지 않는 이상 사용자를 알아내기는 힘들다.
- 단순한 통로라기 보다는 정교한 프라이버시와 보안 역량을 갖춘 암호화된 터널
- VPN 서버에 연결된 사용자 기기의 VPN 클라이언트를 통해 사용자의 모든 트래픽은 암호화됨.
- 장점
- 완벽하게 암호화된 보안 연결과 프라이버시
- 유동적이고 믿을 수 있다
- 단점
- 높은 신뢰성과 완전한 기능은 대부분 유료 서비스
- 무료 서비스는 다소 느리다
VPN 🆚 Proxy 비교
비교 | Proxy | VPN |
---|---|---|
보안성 | 취약함 | 강함 |
익명성 | 보장되지 않음 | 보장됨 |
비용 | 대부분 무료 | 유료 서비스가 더 높은 품질 |
동작 위치 | 브라우저 | 방화벽 |
프로토콜 | HTTP, TELNET, SMTP, FTP | PTTP, L2TP, IPsec |
추천되는 작업 | 간단한 웹 작업 | 복잡한 작업 |
비동기 프로그래밍
읽어 보기 : 파이썬과 동시성 (멀티스레드, 멀티프로세스, 비동기)
- 파이썬에서는 asyncio라는
async/await
구문을 사용 하여 동시성 코드를 작성하는 라이브러리를 사용 - 코루틴은 cooperative routine의 줄인말로 서로 협력하는 루틴이라는 뜻
- python의
coroutine
은 single thread에서 대기시간을 줄여 CPU의 활용을 극대화 시킴 - 동기(Synchronous)
- 현재 작업의 응답 결과가 나오고 난 뒤 순차적으로 다음 작업 요청.
- 작업의 결과가 나왔는지 계속 확인
- 함수가 완료 될 때 까지 리턴하지 않음
- 비동기(Asynchronous)
- 현재 작업의 응답 결과가 나오기전 다음 작업을 요청
- 작업의 결과를 확인하지 않음
- 함수 완료 여부와 상관 없이 호출자에게 리턴하며, 작업이 완료 되면 호출자에게 완료를 통보한다.
비동기 함수를 사용하면 CPU의 유휴 시간을 줄여 전체 프로그램 효율을 향상 시킬 수 있다.
Thread 를 사용한 동시성과의 비교
보통 동시에 여러가지 작업을 처리하게 하려면 별도의 쓰레드를 생성해서 작업을 할당하는데, 파이썬에서는 GIL(Global Interpreter Lock)으로 인해
한 번에 한 쓰레드만 파이썬 코드를 실행할 수 있기 때문에 여러 쓰레드를 쓰는 것이 오히려 비효율적이다.
단, 위 내용은 CPU bound 작업을 할 때에만 해당하는데, 파이썬은 I/O bound 작업들을 할 때에는 GIL 을 해제하여 다른 쓰레드가 이어서 작업을 진행할 수 있도록 되어있어
I/O bound 작업들에 대해서는 여러 개의 쓰레드를 사용해서 효율적인 동시 처리가 가능하기 때문이다.
파이썬에서는 threading 라이브러리나 concurrent 라이브러리를 이용한 멀티쓰레딩이 가능하고, 3.4 부터는 generator 에서 부터
진화해 오던 코루틴을 이용한 비동기 라이브러리인 asyncio 가 추가되어서 좀 더 쉬운 동시적인 처리를 지원하게 되었다.
asyncio 는 threading 과는 달리 하나의 쓰레드를 사용하여 작업들을 동시적으로 처리한다.
출처 : https://nachwon.github.io/asyncio-and-threading/
Nginx
가벼움과 높은 성능을 목표로 한 웹 서버 소프트웨어 (=경량 웹 서버)
- 클라이언트로부터 요청을 받았을 때 요청에 맞는 정적 파일을 응답해주는 HTTP Web Server로 활용
- Reverse Proxy Server로 활용하여 WAS 서버의 부하를 줄일 수 있는 로드 밸런서로 활용
Apache 서버와의 차이
- Apache HTTPd (요청 당 스레드 혹은 프로세스 기반의 구조)
- 받은 요청을 처리할 때 새로운 프로세스 또는 쓰레드를 생성하여 처리
- 접속하는 사용자가 많으면 그만큼 쓰레드가 생성되어 CPU와 메모리 자원의 소모가 커짐
- Nginx (비동기 이벤트 기반 구조)
Event-Driven
구조로 동작하기 때문에 한 개 또는 고정된 프로세스만 생성하여 사용- 비동기 방식으로 요청들을 처리
- 프로세스와 쓰레드 생성 비용 없음, 적은 자원으로도 효율적인 운용이 가능
- 단일 서버에서도 동시에 많은 연결을 처리
Apache | Nginx | |
---|---|---|
동작 방식 | 멀티 스레드 | 단일 스레드 |
장점 | 웹서버 자체 내에서 동적 컨텐츠 처리 | 제한된 리소스로 여러 요청을 효율적으로 처리 |
단점 | 트래픽 부하 시 여러 요청을 동시에 처리 불가 | 동적 컨텐츠 처리불가->외부 프로세스로 전달,렌더링 후 다시 전송 (프로세스 속도 저하) |
사용 목적 | 다양한 동적 모듈이 사용되는 웹 사이트 | 트래픽이 많은 정적 컨텐츠 웹 사이트 |
OAuth 2.0
OAuth2(Open Authorization, Open Authentication 2) : 인증을 위한 표준 프로토콜.
구글, 페이스북, 카카오 등에서 제공하는 Authorization Server를 통해 회원 정보를 인증하고 Access Token을 발급받고 그것을 이용해 타사의 API 서비스를 이용할 수 있다.
- 인증의 과정을 '타 서비스에게 위임' 하는 인증 방식
- 보안의 수준을 알 수 없는 애플리케이션에서 일일이 계정을 만들어 사용하면 ID/PW관리가 어렵고 개인정보가 유출될 가능성이 있음
- 검증된 사이트의 API를 사용하면 보안상의 위험성이 떨어짐
DNS
도메인 네임 시스템(Domain Name System, DNS)
호스트의 도메인 이름을 호스트의 네트워크 주소로 바꾸기 위해 개발됨(반대의 변환도 가능)
- 특정 컴퓨터의 주소를 찾기 위해, 사람이 이해하기 쉬운 도메인 이름을 IP 주소로 변환해 줌 (사람이 IP주소를 외울 수 없으므로)
- 전화번호부와 비슷
www.example.com
과 같은 주 컴퓨터의 도메인 이름을192.168.1.0
과 같은 IP 주소로 변환하고 라우팅 정보를 제공하는 분산형 데이터베이스 시스템
CI/CD
CI (지속적 통합 : Continuous Integration)
개발을 하면서 ‘코드에대한 통합’을 ‘지속적’으로 진행함으로써 품질을 유지하는 것 (=빌드 및 테스트 자동화)
CD (지속적 배포Continuous Deploy 또는 Delivery)
CI 프로세스를 통해 개발중에 지속적으로 빌드와 테스트를 진행하고,
이를 통과한 코드에 대하여 테스트서버와 운영서버에 곧바로 그 내용을 배포해 반영하는 것 (=배포 자동화)
CircleCI
, Travis
, Jenkins
같은 툴을 이용하면 CI/CD 자동화 솔루션을 편하게 구현하도록 도와줌
UDP
UDP (User Datagram Protoco : 사용자 데이터그램 프로토콜)
데이터를 데이터그램 단위로 처리하는 프로토콜
- 비연결형 서비스로 데이터그램 방식을 제공한다
- 정보를 주고 받을 때 정보를 보내거나 받는다는 신호절차를 거치지 않는다.
- UDP헤더의 CheckSum 필드를 통해 최소한의 오류만 검출한다.
- 신뢰성이 낮다
- TCP보다 속도가 빠르다
http 1.1 🆚 2.0
HTTP 1.1의 문제점
HTTP 1.1은 기본적으로 Connection당 하나의 요청을 처리하도록 설계되어 있음. -> 동시 전송 문제와 다수의 리소스를 처리하기에 속도와 성능 이슈를 가짐
- HOL(Head Of Line) Blocking - 특정 응답 지연
하나의 응답이 지연될 시 해당 응답이 완료될 때 까지 다음 요청은 무한대기 - RTT(Round Trip Time) 증가
요청별로 Connection을 만들게 됨 -> 3-way Handshake가 반복적으로 일어남 -> 불필요한 RTT 증가와 네트워크 지연을 초래. - 헤비한 Header 구조
매 요청 시마다 중복된 헤더값을 전송하게 되고, 해당 도메인에 설정된 cookie 정보도 매 요청시 헤더에 포함되므로 전송하려는 값보다 헤더 값이 더 클 수가 있음
HTTP 2.0의 등장 : 속도와 성능 향상
- Multiplexed Streams
한 커넥션에 여러 개의 메시지를 동시에 주고 받을 수 있다. - Stream Prioritization
요청 리소스간의 의존관계(우선순위)를 설정할 수 있다. - Server Push
HTML 문서 상에 필요한 리소스를 클라이언트 요청없이 보낼 수 있다.
HTTP 1.1는 HTML문서를 해석하기 위해 필요한 리소스를 재 요청할 수 있는데, HTTP 2.0에서는 재 요청없이 Server Push 기법을 활용하여 해석이 가능. - Header Compression
Header 정보를 HPACK 압축방식을 이용하여 압축 후 전송한다.
HTTP 2.0에서는 Header에 중복값이 존재하는 경우 중복된 Header는 index값만 전송하고 중복되지 않은 정보 값은 인코딩하여 전송함.
도메인 : 사용자가 검색하는(=기억하기 쉬운) 주소 (건물명 ex.위워크)
호스팅 : 웹사이트를 작동 시키는 컴퓨터 (건물)
IP주소 : 실제 주소 숫자로 이루어진 (건물의 등기부등본상 주소지)
Author And Source
이 문제에 관하여([TIL] 기술면접 대비 정리 2 | 내가보려고 간단하게 정리한 글), 우리는 이곳에서 더 많은 자료를 발견하고 링크를 클릭하여 보았다 https://velog.io/@fore0919/TIL-기술면접-대비-정리-2-내가보려고-간단하게-정리한-글저자 귀속: 원작자 정보가 원작자 URL에 포함되어 있으며 저작권은 원작자 소유입니다.
우수한 개발자 콘텐츠 발견에 전념 (Collection and Share based on the CC Protocol.)