공부기록/기타 (7) 썸네일형 리스트형 reverse proxy 서비스 운영에 있어서 필수적인 proxy server 프록시 종류가 여러가지가 있을 것 입니다. 스프링의 프록시나, 디자인 패턴중에 프록시 패턴도 있을 것이고, reverse proxy는 네트워크 프록시 입니다. 서버측에 가까이 있는 프록시를 리버스 프록시라고 합니다. 클라이언트로 부터 서버의 정보를 숨겨주고, 요청을 어느 서버로 보내줄지에 대하여 로드밸런싱 작업을 해줍니다. 마지막으로, 전형적인 프록시 서버와 같이 캐싱을 해줍니다. reverser proxy에 반대되는 개념인 forward proxy는 보통, 글로벌 서비스에서 다른 국가들에게 빠른 서비스를 제공하기 위해 사용됩니다. 캐싱을 제공하며, 서버로 부터 클라이언트의 정보를 가려줍니다. [git] merge vs rebase merge: 브랜치를 합치는데 사용됩니다. 여기서 rebase를 사용하면 로그가 깔끔해집니다. 다시말하면, 일반적으로 develop 브랜치에서 기능을 개발할때, feature 브랜치를 만들고, 개발이 완료된 후 브랜치를 merge 합니다. 그러나 develop 브랜치에도 그사이에 개발이 될 수 있습니다. 그런 경우, feature에서 develop으로 merge를 하면, feature에서 commit 한 log 뿐만 아니라, 둘 사이에 문제를 없애기 위한 merge commit log가 추가됩니다. 그러나, rebase를 하고 merge를 하는 경우, merge에 관한 commit log가 필요없어집니다. rebase를 하면 feature의 base 가 develop의 최신 브랜치로 바뀌게 되어, 자동으.. http 0.9~ 3 0.9 메서드 종류와 url 1.0 헤더 추가 1.1 여러개를 보낼 수 있는 파이프라이닝 일정시간 동안 connection을 유지함 2.0 항상 같은 헤더를 보내면 문제가 되니까 두번째 보내는 같은 헤더를 압축 스트림을 사용하여 결과값을 한번만 받아도 되도록 수정 (요청과 응답의 다중화) (리소스간 우선 순위 설정) (Server push) 3.0 udp기반의 quic을 사용하여, (지연 불가피)를 극복하고 Tcp 수준의 신뢰성을 확보 기존에는 하나가 잘못되면 처음부터 다시보내야했는데, 이제는 잘못된 부분 하나만 다시 보내게 하게 수정 uuid를 사용하여 server에서 저장할 필요없이 기존의 문제인 파이프라이닝 문제가 여러개를 보냈을 때, 오래걸리면 나머지가 오래걸리는 문제를 해결 TLS 기본 적용 (.. reverse proxy 프록시는 범용적인 용어 - 대리자 ( 원본 객체 이전에 무언가를 처리하는 역할) 네트워크 프록시에서는 클라이언트와 서버간의 중계서버 일반적으로 프록시를 말하면 forward proxy foward proxy - 클라이언트의 정보를 가려줌 ( server가 응답 받은 요청을 누가 보냈는지 알지 못하게 한다.) reverse proxy는 internet과 server의 사이에 있는 프록시 서버 ( 서버로 가기전에 로드밸런싱의 역할을 하는 프록시 서버) (캐싱) , (익명화 - 서버의 정보를 숨길 수 있음, 서버인척 응답을 보내, 익명화를 할 수 있음) , (로드 밸런싱 - 서버에 역할을 분배해준다) 출처. 우아한 tech - reverse proxy 테코톡들 block, non-block / sync, async block: 제어권이 호출자에게 없음 non-block: 제어권이 호출자에게 있음 sync: 결과값이 오면 바로 그것을 실행 async: 결과값이 와도 바로 그것을 실행하지 않아도 됨 A,B 프로세스가 있을 때, A가 B에게 어떤 작업을 요청했다면 blocking은 A가 그동안 대기하는 것 non-blocking은 A가 그동안 다른일을 할 수 있는 것 sync는 B의 작업이 끝나면, 알아채는 즉시 A가 그 작업을 진행하는 것 async는 B의 작업이 끝나면, A가 그 작업을 언제 진행하도 상관이 없는 것 webRTC 개념이해 서버 - 클라이언트의 경우 서버가 브라우저에 그냥 메시지를 전송할 수 없음 → request가 와야지만, response를 줄 수 있음 실시간 서비스를 만드려면 → 계속 서버로 확인 request를 전송해야함 그래서 websocket이 나옴 ( 통신이 열려있는 동안, 서버에서 리퀘스트 필요없이 바로 메시지를 보낼 수 있음/ 리얼타임 경험을 위해 만들어짐- > 채팅방은 웹소켓 서버에 모두가 접속한 것) 서버의 메모리 파워( 유저가 많으면 많을 수록 더 많은 메모리 필요하고, 서버에 더 돈을 써야함, 서버에 많은 비용이 들어감) → 그래서 webRTC (채팅방을 그러면 브라우저끼리 연결하자!) →웹 리얼 타임 커뮤니케이션 ( p2p 커뮤니케이션) 단순 텍스트 뿐만 아니라, 영상, 오디오 등도 다 주고 받을 .. HashTable과 HashMap의 일반적인 차이 HashTable의 코드 public synchronized int size() { return this.count; } public synchronized boolean isEmpty() { return this.count == 0; } public synchronized Enumeration keys() { return this.getEnumeration(0); } public synchronized Enumeration elements() { return this.getEnumeration(1); } synchronized -> thread-safe HashMap synchronized를 사용하지 않음 싱글 스레드 환경에서 더 효율적 이전 1 다음