ໂປຣໂຕຄໍ TCP ທີ່ກຳນົດເອງສາມາດເດີນທາງຜ່ານ proxy HTTP ໄດ້ເມື່ອ proxy ນັ້ນອະນຸຍາດ CONNECT ໄປຫາປາຍທາງ. ໂປຣໂຕຄໍຂອງແອັບພລິເຄຊັນບໍ່ຈຳເປັນຕ້ອງກາຍເປັນ HTTP: HTTP ສ້າງອຸໂມງ ແລ້ວແອັບພລິເຄຊັນກໍແລກປ່ຽນ byte ຂອງຕົນເອງຢູ່ພາຍໃນ.

OpenJDK 25 ສະໜອງເສັ້ນທາງຜ່ານ proxy HTTP ໃນ Socket(Proxy). ການຈັດຕັ້ງປະຕິບັດຂອງມັນເຮັດ ການແລກປ່ຽນ CONNECT ແລະ ສົ່ງ socket ທີ່ເຊື່ອມຕໍ່ແລ້ວຄືນໃຫ້ແອັບພລິເຄຊັນໃຊ້.

Proxy route = new Proxy(
    Proxy.Type.HTTP,
    new InetSocketAddress("proxy.example", 8080));

try (Socket socket = new Socket(route)) {
    socket.setSoTimeout(10000);
    socket.connect(
        InetSocketAddress.createUnresolved("tcp-service.example", 8443),
        5000);
    InputStream input = socket.getInputStream();
    OutputStream output = socket.getOutputStream();
}

ສ່ວນນີ້ໃຊ້ຄລາສຈາກ java.net ແລະ java.io. ແທນຈຸດປາຍທັງສອງ ແລະ ເຮັດການແລກປ່ຽນໂປຣໂຕຄໍກ່ອນອອກຈາກບລັອກ try. ສຳລັບເປົ້າໝາຍ TCP ສາທາລະນະທີ່ໄດ້ຮັບອະນຸຍາດ, ເລືອກຜູ້ສະໝັກ HTTP ຈາກ ບັນຊີ proxy HTTP ຫຼັງຈາກກວດສອບການອະນຸຍາດ CONNECT ສຳລັບພອດຂອງເປົ້າໝາຍນັ້ນແລ້ວເທົ່ານັ້ນ. ທີ່ຢູ່ proxy ແມ່ນບ່ອນທີ່ Java ເຊື່ອມຕໍ່ກ່ອນ; ທີ່ຢູ່ທີ່ສົ່ງໃຫ້ connect ລະບຸບໍລິການທີ່ proxy ຕ້ອງໄປຮອດ.

ປາຍທາງທີ່ຍັງບໍ່ໄດ້ແກ້ໄຂຮັກສາຊື່ໂຮສຂອງມັນໄວ້ສຳລັບຄຳຮ້ອງ CONNECT ຂອງການຈັດຕັ້ງນີ້. ແຕ່ InetSocketAddress ທີ່ແກ້ໄຂແລ້ວກັບສະໜອງທີ່ຢູ່ IP ທີ່ແກ້ໄຂແລ້ວໃຫ້ຄຳຮ້ອງນັ້ນແທນ. ຄວາມແຕກຕ່າງນີ້ສຳຄັນເມື່ອ proxy ຕ້ອງແກ້ຊື່ບໍລິການ ຫຼື ໃຊ້ນະໂຍບາຍທີ່ອີງໃສ່ຊື່ໂຮສ.

ການເຊື່ອມຕໍ່ທີ່ສຳເລັດເຮັດໃຫ້ທ່ານເຫຼືອຫຍັງ

ກະແສທີ່ໄດ້ຮັບຈະພາເອົາຂໍ້ມູນຂອງບໍລິການທີ່ຢູ່ໃນອຸໂມງ. ພວກມັນບໍ່ເປີດເຜີຍການຕອບສະໜອງ HTTP ແຍກຕ່າງຫາກທີ່ແອັບພລິເຄຊັນຂອງທ່ານຄວນອ່ານແລ້ວຖິ້ມ. ການເພີ່ມການແລກປ່ຽນ CONNECT ທີສອງຈະສົ່ງຂໍ້ຄວາມ HTTP ໄປຫາບໍລິການຫຼັງຈາກ JDK ສ້າງອຸໂມງແລ້ວ.

ຕົວຢ່າງກຳນົດເວລາສຳລັບການເຊື່ອມຕໍ່ ແລະ ເວລາສຳລັບການອ່ານ socket; ສິ່ງເຫຼົ່ານີ້ເປັນການຄວບຄຸມແຍກຕ່າງຫາກ ບໍ່ແມ່ນກຳນົດເວລາລວມອັນດຽວສຳລັບໄລຍະແອັບພລິເຄຊັນ.

ການອະນຸຍາດ CONNECT ຍັງເປັນຂອງ proxy. ຈຸດປາຍທີ່ສົ່ງຄຳຮ້ອງເວັບທຳມະດາອາດປະຕິເສດພອດຂອງບໍລິການ ຫຼື ຕ້ອງການການພິສູດຢືນຢັນກ່ອນເປີດອຸໂມງ. ແຍກຄວາມລົ້ມເຫຼວເຫຼົ່ານີ້ອອກຈາກເຊີບເວີທີ່ຮັບອຸໂມງແຕ່ຕໍ່ມາປະຕິເສດໂປຣໂຕຄໍແອັບພລິເຄຊັນຂອງທ່ານ.

ຖ້າໂປຣໂຕຄໍນັ້ນຕ້ອງການ TLS, ໃຫ້ເຈລະຈາ TLS ຜ່ານ socket ທີ່ເຊື່ອມຕໍ່ແລ້ວ ດ້ວຍຊື່ໂຮສທີ່ຕັ້ງໃຈຂອງບໍລິການ ແລະ ການກວດສອບໃບຮັບຮອງປົກກະຕິ. CONNECT ຢ່າງດຽວບໍ່ໄດ້ເຂົ້າລະຫັດກະແສ. ສຳລັບ HTTP API ຈິງ, ລູກຄ້າ HTTP ຍັງເປັນອິນເຕີເຟສທີ່ສະດວກກວ່າ ເພາະມັນຈັດການຂໍ້ຄວາມ HTTP ນຳ.

ບົດຄວາມທີ່ກ່ຽວຂ້ອງ